Locking database cleanup?

[Alexey Lobanov]

Hello all.

On 05/04/06 11:07, Dhruva Krishnamurthy wrote:

> Hello,
>  I was considering the similar problem.

Actually, it is "documented" in smbd(8):

=======
To  shut down a user’s smbd process it is recommended that SIGKILL (-9)
NOT be used, except as a last resort, as this may leave the shared mem‐
ory area in an inconsistent state.
=======

In my opinion, this problem significantly decreases Samba reliability 
and availability. It is quite expensive to restart the whole fileserver 
  subsystem when  many users have open accounting databases at 
non-affected, "healthy" shares.

> 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.

I agree that the master smbd could be a proper place for really 
automatic solution.

Alexey


> 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