smbd as a daemon

[Jeremy Allison]

On Mon, Mar 24, 2014 at 07:02:19PM +0200, Alexander Bokovoy wrote:
> On Mon, Mar 24, 2014 at 6:45 PM, Jeremy Allison <jra at samba.org> wrote:
> > On Mon, Mar 24, 2014 at 06:40:45PM +0200, Alexander Bokovoy wrote:
> >> >
> >> 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.
> >
> > Yeah, but as you're finding, that's an incorrect assumption.
> >
> > You can'task systemd anything about Samba status. All a
> > meta-daemon can say is 'yes I started the service'.
> >
> > You have to ask the service itself if it's up and running.
> >
> >> 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.
> >
> > This is why when we were doing the same thing at SGI
> > for Samba failover clustering the "are you ready"
> > script called into Samba using smbclient before
> > deciding the service was ready.
> >
> > When you get an answer to an SMB1/2/3 request, then
> > you know Samba is ready.
> Yes, with the optimization to not call smbclient when 'systemctl
> status smb.service' says service is shut down.
> 
> systemd has another protocol for telling when the service is ready,
> besides using main process PID --
> http://www.freedesktop.org/software/systemd/man/sd_notify.html
> We can add support to it to provide more reliable way of telling when
> we are really able to serve.

That looks a much more sensible solution for supporting
systemd.

Send me a patch to add that in and I'll review !

Cheers,

	Jeremy.