Locking database cleanup?

[David Collier-Brown]

You wrote:
---
That's not why we worry about sigkill (leaving dead records).

Because a process can't catch or stop sigkill the smbd might
be in the process of allocating new space within the tdb, which
if it is killed might leave the tdb in an inconsistent state
(ie. anyone trying to read it might crash). It's nothing to
do with dead records, we clean them us as we come across
them as previously described.
---

   Is an inconsistant TDB what was happening to Alexey? From
what you said it should either be recovering automaticaly
or crashing all of Samba...

--dave


Alexey Lobanov <A.Lobanov at cro-rct.ru> wrote:
>>> A quite simple sutuation. One SMBD servicing one user said "segfault"
>>> (e.g., because of CUPS interaction problem) and died. Yes, we are in
>>> Brave Robust Unix World, and one daemon death does not affect other
>>> daemons and remote clients. But... the locking database still contains
>>> records related to this non-existent PID, and any new attempts to use
>>> same files fail. The affected share becomes completely unusable until we
>>> restart the *whole* Samba subsystem, killing open files of all the other
>>> innocent clients. Welcome back to the monolythic server.
>>>
>>> Is this behavior normal for Samba 2 and 3 architecture? Or I do not
>>> understand something?
-- 
David Collier-Brown,         | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
davecb at spamcop.net           |                      -- Mark Twain
(416) 223-5943