Red Hat Bugzilla – Bug 126274
up2date corrupts rpm database when run in parallell
Last modified: 2007-11-30 17:07:02 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6)
Description of problem:
When pushed hard in parallell, up2date corrupts the rpm database,
eg an install in parallell with an update with --dry-run
Version-Release number of selected component (if applicable):
Steps to Reproduce:
0. Take a backup of /var/lib/rpm
1. Run the following in parallell:
while true; up2date --install uucp; rpm -e uucp; done
while true; up2date --dryrun --update; done
2. Wait some time until both loops stalls. strace shows both up2date
processes hangs hard. SIGTERM has no effect.
3. Kill the corresponding processes and their parent shells with SIGKILL
4. try an 'rpm -qa', and watch it hang forever
5. rm /var/lib/rpm/__db.???; rpm --rebuilddb to fix, or restore
/var/lib/rpm from backup.
Actual Results: rpm database corrupted
Expected Results: rpm database not corrupted. I guess up2date should
have some locking mechanism like apt-get has.
We found this by accident because two administrators ran up2date at
the same time. The rpm database was totally corrupted and could not be
restored by --rebuilddb.
This is not an up2date bug, but rather a rpm problem. rpm was fixed
in this regard in FC1. I am unaware if rpm has been updated in RHEL3
quarter update releases, but it could probably be fixed in U3?
Ehm, ok. Should I re-file this bug against rpm?
There have been some RPM updates in the previous (before U3) quarterly
Seems to be fixed with the latest versions of rpm+friends, 4.2.2-0.14
and up2date-4.2.33-1. I'm unable to reproduce this on our system now.
The bug may be closed.