Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Date: Fri, 28 Dec 2001 13:16:56 -0801
From: Jos Backus <josb@cncdsl.com>
To: dev@httpd.apache.org
Cc: Aaron Bannert <aaron@clove.org>, Hye-Shik Chang <perky@fallin.lv>
Subject: Re: Running Apache in the foreground
Message-ID: <20011228211718.GE40283@lizzy.bugworks.com>
Reply-To: Jos Backus <josb@cncdsl.com>
Mail-Followup-To: dev@httpd.apache.org, Aaron Bannert <aaron@clove.org>,
	Hye-Shik Chang <perky@fallin.lv>
References: <20011228014444.GA40283@lizzy.bugworks.com>
 <20011228060731.GJ29284@ebuilt.com>
 <20011228090004.GD40283@lizzy.bugworks.com> <20011228100912.H1529@clove.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20011228100912.H1529@clove.org>
User-Agent: Mutt/1.3.24i

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.

/****************************************************************************
 Become a daemon, discarding the controlling terminal.
****************************************************************************/

void become_daemon(BOOL dont_fork)
{
        if (!dont_fork && sys_fork()) {
                _exit(0);
        }

  /* detach from the terminal */
#ifdef HAVE_SETSID
        if (setsid() == -1)
                DEBUG(0, ("setsid() failed: %s\n", strerror(errno)));
#elif defined(TIOCNOTTY)
        {
                int i = sys_open("/dev/tty", O_RDWR, 0);
                if (i != -1) {
                        ioctl(i, (int) TIOCNOTTY, (char *)0);
                        close(i);
                }
        }
#endif /* HAVE_SETSID */

        /* Close fd's 0,1,2. Needed if started by rsh */
        close_low_fds();
}

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

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

#include <unistd.h>
#include "strerr.h"
#include "pathexec.h"

#define FATAL "pgrphack: fatal: "

int main(int argc,const char * const *argv,const char * const *envp)
{
  if (!argv[1]) strerr_die1x(100,"pgrphack: usage: pgrphack child");
  setsid(); /* shouldn't fail; if it does, too bad */
  pathexec_run(argv[1],argv + 1,envp);
  strerr_die4sys(111,"pgrphack: fatal: ","unable to run ",argv[1],": ");
}

But I haven't tested this and I'd much rather see this functionality in httpd
(it's a hack, after all).

> > So the use of the second 0 strikes me as suspicious and likely wrong.
 
OK, I overreacted, sorry. But the macro names should match.

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

> >  The FreeBSD Apache port currently uses a patch located at
> >  http://fallin.lv/distfiles/apache-2.0.28_1.diff; 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 configure.in 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.)
 
I thought it was simply a matter of changing the macro name or adding an extra
definition. Maybe the patch author can comment?

-- 
Jos Backus                 _/  _/_/_/        Santa Clara, CA
                          _/  _/   _/
                         _/  _/_/_/             
                    _/  _/  _/    _/
josb@cncdsl.com     _/_/   _/_/_/            use Std::Disclaimer;