Bug 9511 - rpm hangs when performing operations that require database writes.
rpm hangs when performing operations that require database writes.
Product: Red Hat Linux
Classification: Retired
Component: rpm (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Jeff Johnson
Depends On:
  Show dependency treegraph
Reported: 2000-02-16 21:28 EST by Nathan Valentine
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-02-22 10:29:08 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Nathan Valentine 2000-02-16 21:28:23 EST
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
Comment 1 Jeff Johnson 2000-02-22 05:59:59 EST
What does strace ("strace -o /tmp/xxx rpm ...") say?
Comment 2 Nathan Valentine 2000-02-22 09:21:59 EST
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.
Comment 3 Jeff Johnson 2000-02-22 10:29:59 EST
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.

Note You need to log in before you can comment on or make changes to this bug.