Sorry if this is a duplicate but I didn't have cookies enabled the first
time and I never received a confirmation email.
Running RH 6.1 with all updates as of Feb. 16, 2000.
rpm operations that require a database write hang. For instance:
rpm -Uvh foo.rpm
No warning or error messages. The process does not accept ^C or ^\ and must
be send kill -9 several times. Does not chew up CPU time or hit the disk.
Tried to strace and ltrace to see what was going on but got an "Operation
not permitted" message.
rpm operations that only do reads work fine. For instance:
What does strace ("strace -o /tmp/xxx rpm ...") say?
An interesting follow-up...
I have since been able to strace an rpm session that does writes on the
RPM database. The problem was NFS-related but I believe that it demonstrates
a bug in RPM. When, for instance, trying to install a new RPM the strace would
report that the process was hanging at a stat() on one of our NFS mounts. It
turns out that this volume was hard mounted and someone had moved the machine to
a new network. Somewhere in the RPM code a stat() was being called for each
mounted filesystem. A coworker pointed out that maybe RPM was doing a sync
on each write as a form of file integrity insurance. Sounds plausbile to me
but I have not had time to dive into the code.
If RPM *is* doing a sync on write for each mount, then I suppose that this is
an unintended consequence. In general, it's a design flaw with NFS, but does
RPM really need to do a sync on filesystems to which it is not writing? In our
case, the NFS mount was temp area and RPM was most certainly *not* writing to
RPM does disk space accounting, and hence has to know the space for
each mounted file system used. The algorithm stats all mounted file
systems cuz' it's lots cheaper to get the information once and compute
changes than it is to reacquire the disk space information. RPM does not do
a "sync on write", a simple close is sufficient.