httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <>
Subject Re: Running Apache in the foreground
Date Fri, 28 Dec 2001 18:09:12 GMT
On Fri, Dec 28, 2001 at 12:59:42AM -0801, Jos Backus wrote:
> On Thu, Dec 27, 2001 at 10:07:31PM -0800, Justin Erenkrantz wrote:
> > On Thu, Dec 27, 2001 at 05:44:22PM -0800, Jos Backus wrote:
> > > I'm willing to code a patch which allows Apache to run in the foreground in
> > > its own session. Currently it kills the pgrp it is in even though it didn't
> > > create it (bad practice imo - only destroy what you create).
> > 
> > I'm not sure what version you are talking about (1.3 or 2.0), but 
> > on 2.0 Unix-based MPMs, you can run httpd with -DNO_DETACH and it 
> > will not detach from the terminal.
> > 
> > ./httpd -DNO_DETACH
> > 
> > The only place I'm seeing us killing the process group is when you
> > send a SIGTERM.  Is this what you are talking about?
> Yes, this is with 2.0.28 (the version in the FreeBSD Ports collection) and it
> happens with -DNO_DETACH; yes, we call setpgrp()/setsid()/etc. in
> apr_proc_detach() but that function is not called when using -DNO_DETACH :-)
> What would work in this particular case is to continue to call
> apr_proc_detach() but telling it not to call fork(). Something along these
> lines:

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.

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


> Btw, there is a macro bug affecting apr_proc_detach(): it checks for
> APR_HAVE_SETSID but configure sets HAVE_SETSID. One FreeBSD (and other
> platforms that have setsid()) this causes this code to be used instead of
> setsid():
>     if ((pgrp = setpgid(0, 0)) == -1) {
>         return errno;
>     }
> FreeBSD's setpgid(2) says
>      Setpgid() sets the process group of the specified process pid to the
>      specified pgrp.  If pid is zero, then the call applies to the current
>      process.
> So the use of the second 0 strikes me as suspicious and likely wrong.

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

>  The
> FreeBSD Apache port currently uses a patch located at
>; maybe you can verify this and
> commit this fix so the patch can go away. Hye-Shik Chang told me he entered a
> Apache problem report for this issue.

Can someone perhaps better describe what's happening in this patch, or
provide a patch against directly? I was thinking that we
might want to check for _POSIX_JOB_CONTROL or do some other autoconf
magic to make sure that we have setsid() and that it does what we want.
(Not sure if _POSIX_JOB_CONTROL is supposed to be defined for setsid()
the way it is for setpgid() though.)


> > AIUI, some OSes do not deliver signals 
> > sent to the parent to the children and others do.  I think we were 
> > attempting to obtain consistency.  I imagine we could have httpd 
> > set it own process group, but that might not be good either.  
> > Thoughts?  -- justin
> As I see it, it would be sufficient to do the setsid() without the fork().
> Fwiw, I just sent off a very similar patch to the Samba people in response to
> an e-mail response by Jeremy Allison; nmbd and smbd have the same problem and
> the fix is very similar.

See above.


View raw message