On Jul 26, 2012, at 11:10 PM, Daniel Kahn Gillmor <d...@fifthhorseman.net>
wrote:
> hey folks--
>
> it looks like the sks recon process on zimmermann.mayfirst.org
> (a.k.a. keys.mayfirst.org) stopped about 10 days ago:
>
> 2012-07-16 05:28:34 Raising Sys.Break -- PTree may be corrupted:
> Bdb.DBError("unable to allocate memory for mutex; resize mutex region")
>
> yuck.
>
> After stopping sks, I tried running "db4.8_verify -h PTree ptree", but
> this command seemed to be hanging within a futex() sys call.
Running dbXY_stat -CA (for all status: -Cl is usually all that is needed)
will display "hung" deadlocks.
I can/will try to point out the deadlock if you send -CA output.
Whether that helps resolve the root cause is a different issue;
but it helps to conform "hang" information explicitly.
Usually the deadlock is transient and related to other events.
Meanwhile dbXY_verify isn't the right tool for serious diagnosis
of locking issues.
hth
73 de Jeff
_______________________________________________
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel
