Any strong views on the exact modal for s3fs startup?

[Stefan (metze) Metzmacher]

Hi Andrew,

> 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.

doing an exec() per connection doesn't work, we need a parent smbd!
The parent smbd does a lot of stuff, which is really important for
the overall behavior of smbd, cleanup and all sorts of things.

Doing an exec() per connection would run smbd in inetd mode,
which is mostly untested (and leads to very strange CLEAR_IF_FIRST
semantics)

The only option I can see is using fork() + calling smbd_main()
instead of fork() + exec("smbd"), but that still requires a lot
of work.

We need to make sure the ad fileserver and the standalone fileserver run
100% the same code (using the same code paths)

For now I'd prefer to fix the bugs in the existing model.

metze

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20120601/8b5a3222/attachment.pgp>