|| ||Andrew Tridgell <tridge-AT-samba.org> |
|| ||Jeremy Allison <jra-AT-samba.org> |
|| ||Re: To release Samba 4.0 'as is' |
|| ||Wed, 30 Nov 2011 10:13:30 +1100|
|| ||Article, Thread
> Now how we do that - whether it's one big binary or separate
> communicating processes - is what we finally need to agree
> on. I'm not a fan of one big binary, as you know.
first off, please understand that whatever we do, the resulting binary
will be about 50x smaller than smbd is in our current 3.x releases. So
the 'big binary' problem is just a non-problem if by big you are
referring to size. The 'separate binaries with no shared libraries'
approach used up to this point in Samba 3.x results in vastly larger
binaries for all the components than anything we are doing for the 4.0
So it is not a question of size. It is a question of
architecture. Personally I think that the file server being a module
like all the other modules we have in bin/samba is the best approach.
That said, as this is obviously a sticking point and I clearly haven't
convinced you, so I'm currently reworking my s3fs-wip branch to create a
bin/samba module that launches smbd as a child daemon. It first creates
a custom config file in $PREFIX/private/smbd.tmp/fileserver.conf then
launches $SBINDIR/smbd like this:
/* start it as a child process */
req = samba_runcmd_send(task, task->event_ctx, timeval_zero(), 1, 0,
If you want to look at the rest of the code, then have a look at my
s3fs-wip branch, in the file_server directory. It works for simple tasks
at the moment (eg. smbclient can connect to a share), but more complex
tasks involving some RPC services (such as what smbclient -L does)
fail. I'm currently looking into why this is.
We also need to teach smbd to die when its parent process dies, as
currently killing the samba process leaves a stray smbd behind, so a
restart doesn't work. When run with --foreground it should be monitoring
its parent, either via an event on a pipe or via kill() to ensure it
exits when the parent exits.
to post comments)