smbd as a daemon

Jeremy Allison jra at samba.org
Mon Mar 24 16:16:25 MDT 2014


On Mon, Mar 24, 2014 at 05:56:03PM -0400, Simo wrote:
> On Mon, 2014-03-24 at 09:02 -0700, Jeremy Allison wrote:
> > On Mon, Mar 24, 2014 at 05:00:10PM +0100, Andreas Schneider wrote:
> > > Hello,
> > > 
> > > we have an issue with systemd and smbd (maybe also winbind and nmbd). systemd 
> > > assumes that if the daemon starts up and returns with the exit code SUCCESS 
> > > that it is ready and working. In a systemd service file normally you specify 
> > > the PID file which is used to check if a service is running:
> > > 
> > > systemctl status smb.service
> > > 
> > > 
> > > The problem is that when smbd starts we check if we want to become a daemon. 
> > > If yes, then we fork and the parent exits with 0. Then we create some 
> > > directories and create the pid file. So between the exit and the creation of 
> > > the pid file we have a race condition.
> > > 
> > > The correct thing would be to wait in the parent util the child is done with 
> > > the init and then send a signal it can successfully exit.
> > > 
> > > 
> > > The questions what is suggested way to do this inside of smbd?
> > > 
> > > 
> > > Please help!
> > 
> > Hmmmm. Isn't this breakage inside systemd ? It's common
> > for a daemon to start up, fork and then exit to ensure
> > you've lost your controlling terminal - make you safe
> > to run from the command line as well as from inetd.
> > 
> > Doesn't this break on many other daemons as well ?
> 
> We are changing them in the other upstreams I am involved with because
> systemd's request is sensible and makes things more manageable.
> 
> It is not hard to make this work right.

Sure, but the problem *is* in systemd changing
what it expects from daemons.

I'm not saying what it expects isn't nicer
and a cleaner way of doing things, but people
don't like to be *forced* to change, they'd
rather do the right thing on their own :-).

Systemd has rather too much of the 'my way
or the highway' attitude to it IMHO.

Jeremy.


More information about the samba-technical mailing list