Question on how smbd handles signals (possible bug)
tvrtko.ursulin at sophos.com
tvrtko.ursulin at sophos.com
Wed Sep 24 09:40:54 GMT 2008
Volker Lendecke <Volker.Lendecke at SerNet.DE> wrote on 23/09/2008 19:22:16:
> On Tue, Sep 23, 2008 at 06:31:53PM +0100, tvrtko.ursulin at sophos.com
> > > 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
> > 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
> > 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
> > 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
We will try that as a workaround but in the meatime I agree lets try to
clarify things completely.
Leases were my argument how open system call can block on a standard
system - which means Samba has to handle EINTR or use SA_RESTART for all
signal handlers. If we can agree on that I think that means it is in fact
a bug which needs fixing.
I don't understand the internals of Samba but I find this in smb.conf(5):
kernel oplocks (G)
For UNIXes that support kernel based oplocks (currently only
IRIX and the Linux 2.4 kernel), this parameter allows the use
of them to be turned on or off.
Kernel oplocks support allows Samba oplocks to be broken
whenever a local UNIX process or NFS operation accesses a file
that smbd(8) has oplocked. This allows complete data
consistency between SMB/CIFS, NFS and local file access (and is a
very cool feature :-).
This parameter defaults to on, but is translated to a no-op on
systems that no not have the necessary kernel support. You
should never need to touch this parameter.
Default: kernel oplocks = yes
This suggest that Samba is expecting signals from lock breakers in order
to release files but that is not in line with what you just said. So I am
confused. Why it should be necessary to turn off oplocks, even the man
page says that should never be needed?
Does it matter who is holding the oplock (I don't know who at the moment),
because anyone can take it and is Samba supposed to work correctly then
with oplocks defaulting to on?
Sophos Plc, The Pentagon, Abingdon Science Park, Abingdon,
OX14 3YP, United Kingdom.
Company Reg No 2096520. VAT Reg No GB 348 3873 20.
More information about the samba-technical