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
<pmatilai(a)laiskiainen.org>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
buildsys(a)lists.fedoraproject.**org <buildsys(a)lists.fedoraproject.org>
https://admin.fedoraproject.**org/mailman/listinfo/buildsys<https://ad...
--
Thomas