smbd as a daemon
ab at samba.org
Mon Mar 24 10:40:45 MDT 2014
On Mon, Mar 24, 2014 at 6:13 PM, Andreas Schneider <asn at samba.org> wrote:
> On Monday 24 March 2014 09:02:44 you 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 ?
> But how do you then tell the process which started you, that the startup was
> successful? We will not remove this, we just wait a bit longer until we
> created the pid file and then exit the parent.
> What we have now:
> 1. You start smbd
> 2. smbd does exit(0) (hey we started successfully)
> 3. You check if it is running by checking the pid in /run/smb.pid
> 4. No pid file has been created yet.
> 5. We consider smbd isn't running.
> What systemd expects:
> 1. You start smbd
> 1a. smbd child creates pidfile
> 1b. smbd child tells parent to exit
> 2. smbd does exit(0)
> 3. Checking the pidfile tells us smbd is running.
What is important here is that a service assumed to be operational
once it returns control to the systemd. I.e. connecting to the service
would perform something useful.
Our case is that some clustering software checks that smbd started
(via 'systemctl status smb.service') and then attempts to connect to
smbd with smbclient. The check fails, clustering tool considers
smb.service did not start and reports a failure. It could repeat
'systemctl status smb.service' multiple times but why should it do if
we could simply tell the truth at the point we are ready? Looping with
systemctl is equally bad.
/ Alexander Bokovoy
More information about the samba-technical