Any strong views on the exact modal for s3fs startup?

[Andrew Bartlett]

I've been working recently to try and make s3fs startup more reliable.

Some of you testing Samba4 as an AD DC will have noticed that sometimes
after a 'killall samba' a pid file is left behind by the smbd child,
blocking a restart of Samba.

Also, if for some reason a port required by Samba is being used (be it
88, 389 or quite likely 139/445), we still attempt to start the other
services, rather than fail outright.

For Samba4-internal services, I am planning to have them signal the main
process to say 'failure to startup', and shut the server down.  However,
this made me think about how s3fs starts up.  I spent some time creating
this patch set, which moves the socket listen to the parent 'samba'
process:
https://git.samba.org/?p=abartlet/samba.git/.git;a=shortlog;h=refs/heads/s3fs-parent-listen

The problem with this patch series is that because of socket_wrapper,
the individual 'make test' connections passed across the exec() boundary
are treated as unix domain sockets, not TCP connections.,  smbd can't
cope with non-TCP clients. 

What I would like to do is rather than exec(), I would like to call into
the shared library that already contains the smbd codebase, and have it
run most of the same startup routines as library functions in a fork()ed
child. 

The advantage of this will give us much closer integration: we can
(better than we can with a pile of command line arguments) clearly
indicate that logging is already initialised (stopping the current silly
logging to stdout only), not not write a pid, where the smb.conf is, and
not rely on the semantics of writing out fileserver.conf.  

In short, we can make using s3fs just as seamless and painless for our
users as running the ntvfs server. 

The disadvantage would be that it would no longer be possible to
replicate the file server environment by running just smbd.  (I've not
seen anybody use this mode however.)

I normally prefer to make proposals such as this with patches already in
hand, and the branch above would be a starting point, but I would like
to canvas any very strong views on the matter before I put much more
effort into this.  (And then of course address  detailed concerns when I
have patches).

On the original problem, I do realise that there are other ways to solve
this particular pain point (treat the exit of smbd as fatal, for
example), and I may do that in the shorter term.

Thanks,

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org