From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040207 Firefox/0.8 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): up2date-4.2.16-1 How reproducible: Always 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. Additional info: 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 updates, FWIW.
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. Ingvar