When I run /usr/lib/rpm/rpmdb_stat -CA : Default locking region information: 24857 Last allocated locker ID 0x7fffffff Current maximum unused locker ID 5 Number of lock modes 1000 Maximum number of locks possible 1000 Maximum number of lockers possible 1000 Maximum number of lock objects possible 160 Number of lock object partitions 0 Number of current locks 20 Maximum number of locks at any one time 5 Maximum number of locks in any one bucket 0 Maximum number of locks stolen by for an empty partition 0 Maximum number of locks stolen for any one partition 999 Number of current lockers 1000 Maximum number of lockers at any one time 0 Number of current lock objects 5 Maximum number of lock objects at any one time 1 Maximum number of lock objects in any one bucket 0 Maximum number of objects stolen by for an empty partition 0 Maximum number of objects stolen for any one partition 90021 Total number of locks requested 90021 Total number of locks released 0 Total number of locks upgraded 13509 Total number of locks downgraded 18 Lock requests not available due to conflicts, for which we waited 0 Lock requests not available due to conflicts, for which we did not wait 0 Number of deadlocks 0 Lock timeout value 0 Number of locks that have timed out 0 Transaction timeout value 0 Number of transactions that have timed out 752KB The size of the lock region 46 The number of partition locks that required waiting (0%) 20 The maximum number of times any partition lock was waited for (0%) 0 The number of object queue operations that required waiting (0%) 65 The number of locker allocations that required waiting (0%) 0 The number of region locks that required waiting (0%) 1 Maximum hash bucket length =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
It seems the Number of current lockers is the issue. So the db may no be corrupted but just out of lockers. Any idea on why ? -- Thomas. On Thu, Nov 15, 2012 at 3:13 PM, Panu Matilainen <[email protected]>wrote: > On 11/15/2012 02:58 PM, Thomas wrote: > >> Hi, >> >> In a dev environement on RHEL 6.3, I am running mash (latest git) every 5 >> minutes against 20 koji tags.(both 1.6 and 1.7) >> I am running sequentially the "mash tag" >> After few hours my rpmdb is corrupted and I need to execute db_recover -h >> /var/lib/rpm. >> It seems "createrepo" (0.9.8-5.el6) doesn't release the locks correctly >> everytime. (/usr/lib/rpm/rpmdb_stat -CA) >> Does someone already ran into this issue before I investigate more ? >> > > What kind of errors you're getting from rpmdb? Nearly all the issues > reported as "rpmdb corruption" are something else, such as unclean shutdown > from either a crash or getting forcefully killed while inside Berkeley DB > calls. Which does prevent rpmdb opens until dealt with (db_recover being > one possibility), but it isn't corruption per-se. > > - Panu - > > -- > buildsys mailing list > [email protected].**org <[email protected]> > https://admin.fedoraproject.**org/mailman/listinfo/buildsys<https://admin.fedoraproject.org/mailman/listinfo/buildsys> -- Thomas
-- buildsys mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/buildsys
