Question on how smbd handles signals (possible bug)

Volker Lendecke Volker.Lendecke at SerNet.DE
Tue Sep 23 18:22:16 GMT 2008

On Tue, Sep 23, 2008 at 06:31:53PM +0100, tvrtko.ursulin at wrote:
> > Ok, which process is sending us the signal? In normal
> > operations, this should not happen. The only signal that we
> > expect here is the TERM signal which shuts us down anyway.
> I don't know - I thought it's something internal? Grepping throught the 
> source code I found:
> ./smbd/aio.c:#define RT_SIGNAL_AIO (SIGRTMIN+3)
> ./smbd/oplock_linux.c:#define RT_SIGNAL_LEASE (SIGRTMIN+1)
> One of these two perhaps? But I failed to figure out how they match this 
> from the strace:
> 6219  --- SIGRT_4 (Real-time signal 2) @ 0 (0) ---
> Let alone how SIGRT_4 == Real-time signal 2 ? 
> smbd/aio.c in initialize_async_io_handler definitely sets up a signal 
> handler without SA_RESTART, and linux_init_kernel_oplocks in 
> smbd/oplock_linux.c does the same. I just don't know does any of these two 
> in fact is SIGRT_4 as logged by strace...

Ok, lets try to sort things: The RT_SIGNAL_LEASE is for the
one who owns a lease. This signal can happen *any* time, as
signals usually can. If your box is a pure Samba server,
just set "kernel oplocks = no" and it won't happen anymore.
I thought you were talking about the open being blocked
waiting for an oplock and during that time getting a signal.
Who is holding the oplock in your case? Samba can't be that,
because we give up leases using locking.tdb before we do the

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url :

More information about the samba-technical mailing list