On Fri, Dec 28, 2001 at 01:16:56PM -0801, Jos Backus wrote:
> On Fri, Dec 28, 2001 at 10:09:12AM -0800, Aaron Bannert wrote:
> > AIUI the reason we call fork() before calling setsid() is to guarantee
> > that we are _not_ the process group leader. Calling setsid() will fail
> > if the calling process has the same PID as process group ID.
>
> I haven't tried this (yet) with Apache but a similar approach with {n,s}mbd
> seems to work properly. Here is what the code in
> samba-3.0-alpha12/source/lib/util.c looks like. I don't see the setsid()
> failing with dont_fork == 1.
This only works because there is another fork happening before the call
to setsid(), either an explicit fork() or samba is being started as a
child of another process group member (like a shell script).
> > It seems like I'm missing something here, and I guess I don't quite
> > understand the problem that you're describing. Is this only a problem
> > with NO_DETACH? Please realize that NO_DETACH is a debugging tool.
>
> I know that, and I am trying to find a way to implement a -DFOREGROUND flag as
> a variation on the NO_DETACH flag, which means that the parent httpd stays
> around instead of forking and exiting.
Ok, now that I understand what you're trying to do a little better, I may
be able to offer some help. The biggest pain in implementing this will
be the need to update all of the MPMs with the new -D check. Others may
offer a better way to do this but for now I don't see one.
> > I may be wrong here, but I don't think it was the intention of NO_DETACH
> > to support auto-daemonizing tools. Apache does that already (although
> > perhaps not the way we thought it did).
>
> I am coming into this from a sysadmin point of view. I want to be able to use
> a process monitor (AIX's SRC/daemontools/whatever) because it avoids code
> dauplication and pid file races, handles automatic restarts and provides me
> with a single platform-indendent management interface.
>
> In order for httpd to support this mode of operation it should not fork (and
> decouple itself from its parent) but still run in its own process group, so
> that this pgrp only contains it and its children. A workaround would be to use
> the pgrphack program that comes with daemontools, which looks like this:
Hmm.. You'll have to ensure by other means that httpd is not a process
group leader, most likely by ensuring that httpd is started by another
process and not interactively by the shell.
...
> > > So the use of the second 0 strikes me as suspicious and likely wrong.
>
> OK, I overreacted, sorry. But the macro names should match.
Justin committed a fix for this, let us know if it doesn't work for you.
> > Just to add to what Justin said, setpgid(0,0) effectively means "create a
> > new process group with the calling process as the process group leader". If
> > we were to call setsid() (which seems like we should be doing) we'd ensure
> > that we are fully detaching from the controlling terminal. Of course, this
> > *must* happen after a fork().
>
> Could it be that the process supervisor does something special to make this
> work? That could explain why the Samba daemons seem to run properly under the
> process monitor with my patch.
Yes.
-aaron
