Question on how smbd handles signals (possible bug)

[tvrtko.ursulin at sophos.com]

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

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?

Tvrtko


Sophos Plc, The Pentagon, Abingdon Science Park, Abingdon,
OX14 3YP, United Kingdom.

Company Reg No 2096520. VAT Reg No GB 348 3873 20.