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: rpm -qa
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 that mount.
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.