Blocking SIGTERM in nmbd, why?

Jeremy Allison jra at
Sat Jan 24 05:41:10 GMT 2009

On Fri, Jan 23, 2009 at 11:22:13AM +0100, Stefan (metze) Metzmacher wrote:
> Hi Jeremy,
> why do we block SIGTERM in nmbd most of the time?
> You added it in 1997, see
> The only reason I can see for this is that the sig_term() function,
> really does the shutdown directly at this time, see

Yes, that sounds familiar. The goal of blocking SIGTERM
and others was that would only take signals in the select()
statement, blocking them at all other times so that we'd
not have to deal with signal-safe system call issues such
as having send() or read() return EINTR.

This was one of my earlier attempts to deal with the problem
of non-signal safe code elsewhere in Samba. We're much
more aware of signal issues now, so this might be ok to

> But now that the signal handler only sets the do_sigterm flag,
> I can't see the reason why we should still block SIGTERM.
> I think removing the signal handler temporary when we do
> the interface detection loop is ok for now. But we
> should not block SIGTERM the rest of the time.
> Please review this commits:

Parts of nmbd are still not signal-safe. Look
at the sendto() call in send_udp() in libsmb/nmblib.c.
To make this signal-safe we'd need to change it to

This is probably ok for dealing with SIGTERM as
we want to quit in the case anyway. But there
remain places where we restart the system call
when interrupted with EINTR and places we don't.
We should be consistent in this (the sendto
call above was just one of the places I noticed,
I haven't had time today to scan for more).


More information about the samba-technical mailing list