On Fri, Dec 28, 2001 at 12:59:42AM -0801, Jos Backus wrote:
> Controller as well as Dan Bernstein's daemontools. As a sysadmin, this is
> something I am interested in. I am of course willing to do the rest of the
> coding and doc updates for this.
Well, looking at it, it may be better to just create the process
group rather than modify apr_proc_detach as that function also
remaps 0, 1, 2 fds which isn't what we want with NO_DETACH (or at
least that's not what I want). So, we may need to create some
APR funcs to emulate setsid *or* we just bite the bullet and
create the process group directly in the MPM?
I'm not sure how portable the notion of a process group is and
whether we could provide an APR function for it. Win32 folks?
> 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;
> }
Regarding the macro, I'm comfortable changing that check in
procsup.c:75 to HAVE_SETSID as we check HAVE_WAITPID a few lines
down (and procsup.c includes apr_private.h via threadproc.h).
I forget when we're supposed to use APR_ and when we're not.
> 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. 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.
Regarding the setpgid manpages on various platforms, it seems that
the second 0 indicates that the pid==pgid and that pid becomes the
session leader. I'm not sure how that is incorrect here. This
call should be occurring before the fork, so that sounds correct
to me. What exactly is suspicious here? -- justin
