Locking database cleanup?

[Dhruva Krishnamurthy]

Hello,
 I was considering the similar problem. A solution proposal:

The advantage we have is that we have a SMBD daemon process running.

The main daemon process can have signal handlers for SIGCHLD for SMBD
child prcesses that it forks. When a child SMBD process
terminates/exits, the parent can trigger a cleanup. The cleanup can be
implemented either as a seperate executable or a thread. To avoid the
cleanup routine from getting called for all child processes (on their
exit), some IPC between child & parent could be established to inform
the parent (daemon) when child exits normally.

Having an external tool to cleanup may not be such a good idea.
Depending on PID to identify the cleanup in the TDB may fail if the OS
assigns a recently terminated PID to the new process. When the tool
runs, it will find there is a valid process with this PID and skip the
cleanup. The probability of ths occurance might be real remote!

with best regards,
dhruva

On 4/5/06, Alexey Lobanov <A.Lobanov at cro-rct.ru> wrote:
> Hello all.
>
> 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?
>
> I suspect that "locking.tdb" file contents is secondary thing in this
> case. The primary reason is located in the shared memory machinery. Correct?
>
> And the practical solution could be a tool cleaning locking tables from
> records related to non-existent PIDs...
>
> Alexey
>


--
Dhruva Krishnamurthy
GNU/FSF member: 1935