[5141] in testers
RPM DB corruption in Linux Athena 9.1 alpha
daemon@ATHENA.MIT.EDU (Greg Hudson)
Sun Apr 28 00:51:07 2002
Date: Sun, 28 Apr 2002 00:51:04 -0400
Message-Id: <200204280451.AAA32189@error-messages.mit.edu>
From: Greg Hudson <ghudson@MIT.EDU>
To: testers@MIT.EDU
Garry has noted some RPM DB corruption on a 9.1 alpha Linux machine.
I believe this could have arisen in one of two ways:
* I built the staging rpmupdate with Red Hat 7.2 db and rpm
libraries. Running the resulting binary on a Red Hat 7.1 system
might not work quite right.
* The build root on kenmore had rpm 4.0.3 RPMs in it, so the 9.1
alpha rpmupdate was built against those libraries. It's quite
possible that those libraries are rather buggy compared to the
current 4.0.4-7x.
I rebuilt the staging rpmupdate against Red Hat 7.1 rpm-4.0.4-7x
libraries, after inspecting the source and deciding that all of the
relevant bugs had been fixed. I have also updated kenmore's build
root and rebuilt athena-rpmupdate. I hope these measures will prevent
us from seeing any corruption problems during beta.
One problem still troubles me: Garry and I have both seen updates hang
at the end. The problem seems to be that a duplicate of rpm's stdout
file descriptor is being held open by a program called minilogd, so
that the "tee" command which logs the update doesn't exit. Things I
don't understand:
* What the hell starts minilogd. It's owned by the initscripts RPM,
but initscripts doesn't seem to start it; neither does anything in
/etc/init.d, and it doesn't seem to be running on any of the
systems I've checked.
* How minilogd is being started such that all the excess file
descriptors aren't closed; normally, the "daemon" command in
init.d scripts takes care of that.
* Why the rpmlib fixes I pushed through back in April 2001 didn't
prevent this problem. It may be that all the hung updates
happened with an rpmupdate linked against rpm-4.0.3, in which case
we shouldn't see this problem again.
