Unknown code adb 10 : cannot lock database error

[Ken Raeburn]

On Nov 10, 2010, at 12:47, Shivakeshav Santi wrote:
> HI Ken,
> 
>   Thank you for the response. When we see these errors, usually large batches of Ids are being created or modified. Often it is not a problem, because processes try again and get through.

Ah, that could well do it.  I don't know how long the time intervals are over which the database is locked or unlocked in such a case, but I could certainly see it occasionally being locked for all five attempts.  It might be better if we used usleep and tried more often during those five seconds... and maybe made attempts for longer, too, though some client programs might start timing out if we stall too long.

> There was one instance when none of the processes were able to get through (I think due to a deadlock) and we had to restart the KDC. Are you doing a row level locking and is there a potential for a deadlock in the software ?

Row level locking?  You give us way too much credit. :-)
Our locking strategy dates back to the dbm ("locking? what's that?") days.  We use a POSIX file lock to mediate read-only or read-write access to the database file.  These days, we use Berkeley DB (1.85 with patches) by default, and maybe it's got locking capabilities we should be taking advantage of instead.  But as far as I recall hearing, lock contention is almost never a problem... except for you. :-(

Our locking setup is a bit clunky, but not terribly complicated.  I'd be surprised if there were deadlock cases (other than one involving "permanent" locks used while swapping in a new database, which if interrupted requires more manual intervention than restarting the KDC), but perhaps there's an error path that isn't handling properly or something.

Ken


-- 
Ken Raeburn / raeburn at mit.edu
NOT working or speaking for the MIT Kerberos Consortium