Locking database cleanup?
A.Lobanov at cro-rct.ru
Wed Apr 5 12:16:00 GMT 2006
On 05/04/06 11:07, Dhruva Krishnamurthy wrote:
> 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
> 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,
> 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...
> Dhruva Krishnamurthy
> GNU/FSF member: 1935
More information about the samba-technical