Re: [TEST] Apache 1.3.26 Release Candidate for Testing
On Tue, Jun 18, 2002 at 02:25:36PM -0700, Jos Backus wrote: > --show-layout Hm, configure exits 0 before it's done generating files when show_layout=1. Any idea why this is? I commented out the ``exit 0'' and things seem to work just fine. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: [TEST] Apache 1.3.26 Release Candidate for Testing
Something seems wrong with the shadow tree support. I am seeing this on Solaris 8: kodo:~/src% gtar xzvf ~josb/apache_1.3.26.tar.gz kodo:~/src% mv apache_1.3.26 apache-1.3.26 kodo:~/src% cd apache-1.3.26 kodo:~/src/apache-1.3.26% ./configure \ --shadow=/depot/src/apache-1.3.26 \ --exec-prefix=/depot/pkg/apache-1.3.26 \ --with-port=1680 \ --enable-shared=max \ --with-perl=/usr/local/bin/perl \ --prefix=/depot/pkg/apache-1.3.26 \ --includedir=/depot/pkg/apache-1.3.26/include \ --mandir=/depot/pkg/apache-1.3.26/man \ --sysconfdir=/usr/home/apache/etc \ --datadir=/usr/home/apache/share \ --localstatedir=/usr/home/apache/var \ --runtimedir=/usr/home/apache/var/run \ --logfiledir=/usr/home/apache/var/log \ --proxycachedir=/usr/home/apache/var/proxy \ --show-layout Configuring for Apache, Version 1.3.26 + using installation path layout: Apache (config.layout) + creating external package shadow tree (/depot/src/apache-1.3.26) /depot/src/apache-1.3.26/cgi-bin/printenv [snip] kodo:~/src/apache-1.3.26% cd /depot/src/apache-1.3.26 kodo:/depot/src/apache-1.3.26% make make[1]: Entering directory `/depot/src/apache-1.3.26' make[1]: Makefile.sun4u-sun-solaris2.280: No such file or directory make[1]: *** No rule to make target `Makefile.sun4u-sun-solaris2.280'. Stop. make[1]: Leaving directory `/depot/src/apache-1.3.26' make: *** [all] Error 2 What am I doing wrong? -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: is httpd a valid way to start Apache?
On Thu, May 16, 2002 at 07:27:46PM -0700, Manoj Kasichainula wrote: > On Wed, May 15, 2002 at 12:49:46PM -0701, Jos Backus wrote: > > It would be great to have a BSD-licensed version of > > something like djb's daemontools. > > I've (mostly) written replacements for supervise, setuidgid, and > tcpserver. They use Single Unix APIs, haven't been ported to APR, and > have no docs yet, but they are working for me. > > I imagine porting them to APR wouldn't be too painful, though they > wouldn't remain the svelte 4-8kB binaries they are today. :) Interesting. I'm not sure how much benefit there would be from using APR though. > supervise /var/supervise/producer | supervise /var/supervise/consumer Thanks for the nice explanations. > In my supervise replacement, I use a technique picked up from the > Awesome Might that is Dean (and which was used in some of the early > MPMs). Create a pipe, and keep both ends of it. Create a signal > handler for SIGCHLD that writes to the pipe. And, in the select() call > you reference, wait on both the sigchld pipe (a.k.a. pipe_of_death) > and the named fifo. This sounds like the self-pipe trick (see http://cr.yp.to/docs/selfpipe.html). Neat. > Are people interested in this code? I for one would be interested in seeing this. I may be able to sell this to the FreeBSD people for inclusion in the base OS if the license allows it. Do you also have equivalents to svc, svstat and svok? -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: is httpd a valid way to start Apache?
I wrote: > It would be great to have a BSD-licensed version of something like djb's > daemontools. > That would be totally fine/cool. Are you volunteering? :-) I would if I was even half as decent a programmer as some of you :-) Seriously, a decent process controller that would allow starting, stopping and sending various signals to a command that runs as its child (i.e. duplicating supervise's functionality) should not be too hard to implement. It's the fiddling with the pipes between two supervise's (the main one and the log/ one) that seems tricky to me. And I'd not sure how you'd wait() for the child while still being able to select() on a name pipe in order to read control messages sent by svc. But those details can be worked out, and yes, I'd certainly be willing to lend a hand. The main point is that if such a set of tools were to be made available with a friendly license, would people such as the Apache developers promote them and use them? UNIX needs a standard cross-platform process monitoring solution so individual daemons can stop reinventing the wheel, and the standard control interface will make life easier for sysadmins. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: is httpd a valid way to start Apache?
What about moving into the other direction and moving the process management portion into a separate set of tools so it can be used with other daemons besides httpd? This would also improve portability of the mechanism: no worries about pid file races and staleness, differing versions of ps/kill/killall/etc. It would be great to have a BSD-licensed version of something like djb's daemontools. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: Deamon tools
On Mon, May 13, 2002 at 03:23:54PM -0700, Aaron Bannert wrote: > On Mon, May 13, 2002 at 03:15:44PM -0700, [EMAIL PROTECTED] wrote: > > In that case I'd suggest we do > > > > if (setsid() fails) > > always log error > > exit(1) unless no_detach. > > should that be > exit(1) if no_detach > ? or do I have the logic backward? We should exit if setsid() fails and we don't want to detach (i.e. no_detach). If we don't exit at that point we will end up killing processes in the wrong pgrp later. So I think Aaron's right. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: Deamon tools
On Mon, May 13, 2002 at 03:04:01PM -0700, Aaron Bannert wrote:
> I think we should just fail with an error if the user wished to start
> up under daemontools mode (no_detach mode) but somehow started httpd
> as a process group leader.
That's a good idea ("Doctor, it hurts when I poke here." ...).
> -aaron
--
Jos Backus _/ _/_/_/Santa Clara, CA
_/ _/ _/
_/ _/_/_/
_/ _/ _/_/
[EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: Deamon tools
On Mon, May 13, 2002 at 02:50:34PM -0700, [EMAIL PROTECTED] wrote: > > Hmm - not entirely trivial; it turns out that most unix-es do not take > > kindly to > > > > setsid() > > > > when not detached/non-root. So I changed Jos/Michaels patch. See below. > > Anyone any comments ? > > The other obvious way is to make the error non fatal or do a (!geteuid()) > to see if we are running as root. But wait, if we skip the setsid() if !do_detach we will end up killing the parent pgrp which contains - in this case - svscan/supervise/others, which is part of the point of this patch. Am I missing something? -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: 1.3.26
On Mon, May 13, 2002 at 01:29:23PM -0700, Aaron Bannert wrote: > On Mon, May 13, 2002 at 12:25:39PM -0701, Jos Backus wrote: > > Anyone interested in picking this up before the next (last?) 1.3 release? > > > > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7628 > > I would like to see this go in to 1.3. I will volunteer my time to see > that this happens (the patch is there, it just needs to be merged), if > I can get enough support. I realize this might be considered a feature, > but I think it is something that is needed and will be very useful for > those who are stuck on 1.3 for the time being. Thank you very much! > -aaron -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: 1.3.26
Anyone interested in picking this up before the next (last?) 1.3 release? http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7628 Please? Thanks! -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: 1.3.26
On Fri, Apr 19, 2002 at 02:01:30PM -0500, William A. Rowe, Jr. wrote: > >Perhaps somebody can look at bug 7628? Please? > > That's not a showstopper to rolling .26 - but if someone would update that > patch > in contrib it would be appreciated by many, I'm sure. > > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7628 It would be even better if the patch were integrated so we wouldn't have to do the version chase every time :-) Now when the next version comes out and the patch doesn't apply I'll have to resubmit another bugreport. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: 1.3.26
On Fri, Apr 19, 2002 at 09:24:47AM -0400, Jim Jagielski wrote: > At 2:37 PM +0200 4/19/02, Graham Leggett wrote: > > > >Is it possible to create a 1.3.26 release which includes all the proxy > >fixes to date? > > > > I'm +1 for a 1.3.26... Perhaps somebody can look at bug 7628? Please? -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: [PATCH] -DNO_DETACH and/or apr_proc_detach() confusion?
On Mon, Apr 01, 2002 at 09:07:28PM -0500, Jeff Trawick wrote: > I'll forget about it for now (but I will commit a cleanup of > apr_proc_detach() which won't change the semantics). For the long > term I guess I want -DFOREGROUND and appropriate support in > apr_proc_detach(). Please, please don't change the semantics because it will make it again impossible to run Apache under a process controller. While I'm here, would anybody please have a look at bug 7628? Thanks. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: daemontools/foreground support in 1.3.*
On Thu, Feb 28, 2002 at 01:29:35AM -0800, Justin Erenkrantz wrote:
> http://www.apache.org/dist/httpd/contrib/patches/1.3/daemontools.patch
>
> This should give you an "official" place to download it. I
> have also added a note in 1.3's STATUS.
Btw, the above patch no longer applies cleanly to 1.3.24. Can you please
update the patch with the one attached to this message?
Thanks!
--
Jos Backus _/ _/_/_/Santa Clara, CA
_/ _/ _/
_/ _/_/_/
_/ _/ _/_/
[EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
--- src/main/http_main.cSat Mar 23 00:26:38 2002
+++ src/main/http_main.cSat Mar 23 00:30:17 2002
@@ -341,6 +341,8 @@
static int one_process = 0;
+static int do_detach = 1;
+
/* set if timeouts are to be handled by the children and not by the parent.
* i.e. child_timeouts = !standalone || one_process.
*/
@@ -1349,7 +1351,7 @@
#ifdef WIN32
fprintf(stderr, "Usage: %s [-D name] [-d directory] [-f file] [-n service]\n",
bin);
fprintf(stderr, " %s [-C \"directive\"] [-c \"directive\"] [-k signal]\n",
pad);
-fprintf(stderr, " %s [-v] [-V] [-h] [-l] [-L] [-S] [-t] [-T]\n", pad);
+fprintf(stderr, " %s [-v] [-V] [-h] [-l] [-L] [-S] [-t] [-T] [-F]\n", pad);
#else /* !WIN32 */
#ifdef SHARED_CORE
fprintf(stderr, "Usage: %s [-R directory] [-D name] [-d directory] [-f file]\n",
bin);
@@ -1357,7 +1359,7 @@
fprintf(stderr, "Usage: %s [-D name] [-d directory] [-f file]\n", bin);
#endif
fprintf(stderr, " %s [-C \"directive\"] [-c \"directive\"]\n", pad);
-fprintf(stderr, " %s [-v] [-V] [-h] [-l] [-L] [-S] [-t] [-T]\n", pad);
+fprintf(stderr, " %s [-v] [-V] [-h] [-l] [-L] [-S] [-t] [-T] [-F]\n", pad);
fprintf(stderr, "Options:\n");
#ifdef SHARED_CORE
fprintf(stderr, " -R directory : specify an alternate location for shared
object files\n");
@@ -1380,6 +1382,7 @@
#endif
fprintf(stderr, " -t : run syntax check for config files (with
docroot check)\n");
fprintf(stderr, " -T : run syntax check for config files (without
docroot check)\n");
+fprintf(stderr, " -F : run main process in foreground, for process
+supervisors\n");
#ifdef WIN32
fprintf(stderr, " -n name : name the Apache service for -k options
below;\n");
fprintf(stderr, " -k stop|shutdown : tell running Apache to shutdown\n");
@@ -3370,14 +3373,16 @@
!defined(BONE)
/* Don't detach for MPE because child processes can't survive the death of
the parent. */
-if ((x = fork()) > 0)
- exit(0);
-else if (x == -1) {
- perror("fork");
- fprintf(stderr, "%s: unable to fork new process\n", ap_server_argv0);
- exit(1);
+if (do_detach) {
+if ((x = fork()) > 0)
+exit(0);
+else if (x == -1) {
+perror("fork");
+ fprintf(stderr, "%s: unable to fork new process\n", ap_server_argv0);
+ exit(1);
+}
+RAISE_SIGSTOP(DETACH);
}
-RAISE_SIGSTOP(DETACH);
#endif
#ifndef NO_SETSID
if ((pgrp = setsid()) == -1) {
@@ -5308,7 +5313,7 @@
ap_setup_prelinked_modules();
while ((c = getopt(argc, argv,
- "D:C:c:xXd:f:vVlLR:StTh"
+ "D:C:c:xXd:Ff:vVlLR:StTh"
#ifdef DEBUG_SIGSTOP
"Z:"
#endif
@@ -5330,6 +5335,9 @@
case 'd':
ap_cpystrn(ap_server_root, optarg, sizeof(ap_server_root));
break;
+ case 'F':
+ do_detach = 0;
+ break;
case 'f':
ap_cpystrn(ap_server_confname, optarg, sizeof(ap_server_confname));
break;
@@ -7211,9 +7219,9 @@
reparsed = 1;
}
-while ((c = getopt(argc, argv, "D:C:c:Xd:f:vVlLz:Z:wiuStThk:n:W:")) != -1) {
+while ((c = getopt(argc, argv, "D:C:c:Xd:fF:vVlLz:Z:wiuStThk:n:W:")) != -1) {
#else /* !WIN32 */
-while ((c = getopt(argc, argv, "D:C:c:Xd:f:vVlLesStTh")) != -1) {
+while ((c = getopt(argc, argv, "D:C:c:Xd:fF:vVlLesStTh")) != -1) {
#endif
char **new;
switch (c) {
@@ -7335,6 +7343,9 @@
&& ap_server_root[strlen(ap_server_root) - 1] == '/')
ap_server_root[strlen(ap_server_root) - 1] = '\0';
break;
+ case 'F':
+ do_detach = 0;
+ break;
case 'f':
Re: daemontools/foreground support in 1.3.*
On Tue, Feb 26, 2002 at 07:49:34PM -0800, Jos Backus wrote: > On Tue, Feb 26, 2002 at 07:21:16AM -0800, Aaron Bannert wrote: > > On Mon, Feb 25, 2002 at 05:26:44PM -0500, Michael Handler wrote: > > > hi, guys. i've posted this patch for foreground/supervise support > > > > FWIW, by just eyeballing this patch I can say it looks good. It is > > exactly how I would have done it. > > Fwiw, same here. It is very unintrusive, less so even than the patch that went > into 2.0. Please consider including it. Fyi, I plan on submitting a patch to the FreeBSD port maintainer to include this patch automatically in 1.3.24 when it is released. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: daemontools/foreground support in 1.3.*
On Fri, Mar 01, 2002 at 01:03:33AM -0500, Michael Handler wrote: > | I am of the mind that it should not be added, but I won't stop anyone > | if they garner 3 +1s from actual testing and feedback. Does my +1 count? -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: daemontools/foreground support in 1.3.*
On Tue, Feb 26, 2002 at 07:21:16AM -0800, Aaron Bannert wrote: > On Mon, Feb 25, 2002 at 05:26:44PM -0500, Michael Handler wrote: > > hi, guys. i've posted this patch for foreground/supervise support > > FWIW, by just eyeballing this patch I can say it looks good. It is > exactly how I would have done it. Fwiw, same here. It is very unintrusive, less so even than the patch that went into 2.0. Please consider including it. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: Running Apache in the foreground
On Thu, Feb 21, 2002 at 10:57:49AM -0800, Aaron Bannert wrote: > Thanks for the original patch! I just committed the last chunk from > the patch I posted last week, so we should be good to go. Heh, I caught the commit in ViewCVS when it was only 66 seconds old :) Thanks to you, Justin, Michael Handler and all the other people involved in adding this valuable functionality to an already great webserver! I'm looking forward to the 2.0 release. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: Running Apache in the foreground
Hello Aaron, On Thu, Feb 14, 2002 at 03:01:11PM -0800, Aaron Bannert wrote: > Test it and give it your blessing. +2 ;-) -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: Running Apache in the foreground
netware/procsup.c 2 Aug 2001 20:29:14 - 1.1
+++ srclib/apr/threadproc/netware/procsup.c 13 Jan 2002 21:35:15 -
@@ -54,7 +54,7 @@
#include "threadproc.h"
-apr_status_t apr_proc_detach(void)
+apr_status_t apr_proc_detach(int dont_fork)
{
#if 0
int x;
@@ -64,15 +64,18 @@
#if !defined(MPE) && !defined(OS2) && !defined(TPF) && !defined(BEOS)
/* Don't detach for MPE because child processes can't survive the death of
the parent. */
-if ((x = fork()) > 0)
-exit(0);
-else if (x == -1) {
-perror("fork");
-fprintf(stderr, "unable to fork new process\n");
-exit(1); /* we can't do anything here, so just exit. */
+if (!dont_fork) {
+ if ((x = fork()) > 0)
+ exit(0);
+ else if (x == -1) {
+ perror("fork");
+ fprintf(stderr, "unable to fork new process\n");
+ exit(1); /* we can't do anything here, so just exit. */
+ }
+/*RAISE_SIGSTOP(DETACH);*/
}
-/*RAISE_SIGSTOP(DETACH);*/
#endif
+
#if APR_HAVE_SETSID
if ((pgrp = setsid()) == -1) {
return errno;
Index: srclib/apr/threadproc/os2/proc.c
===
RCS file: /home/cvspublic/apr/threadproc/os2/proc.c,v
retrieving revision 1.47
diff -u -r1.47 proc.c
--- srclib/apr/threadproc/os2/proc.c26 Oct 2001 02:31:04 - 1.47
+++ srclib/apr/threadproc/os2/proc.c13 Jan 2002 21:35:15 -
@@ -618,9 +618,7 @@
return APR_SUCCESS;
}
-
-
-APR_DECLARE(apr_status_t) apr_proc_detach()
+APR_DECLARE(apr_status_t) apr_proc_detach(int dont_fork)
{
return APR_ENOTIMPL;
}
Index: srclib/apr/threadproc/unix/proc.c
===
RCS file: /home/cvspublic/apr/threadproc/unix/proc.c,v
retrieving revision 1.53
diff -u -r1.53 proc.c
--- srclib/apr/threadproc/unix/proc.c 11 Nov 2001 05:51:00 - 1.53
+++ srclib/apr/threadproc/unix/proc.c 13 Jan 2002 21:35:15 -
@@ -362,13 +362,13 @@
}
newargs[i + 2] = NULL;
if (attr->detached) {
-apr_proc_detach();
+apr_proc_detach(0);
}
execve(SHELL_PATH, (char * const *) newargs, (char * const *)env);
}
else {
if (attr->detached) {
-apr_proc_detach();
+apr_proc_detach(0);
}
execve(progname, (char * const *)args, (char * const *)env);
}
Index: srclib/apr/threadproc/unix/procsup.c
===
RCS file: /home/cvspublic/apr/threadproc/unix/procsup.c,v
retrieving revision 1.33
diff -u -r1.33 procsup.c
--- srclib/apr/threadproc/unix/procsup.c28 Dec 2001 19:03:48 - 1.33
+++ srclib/apr/threadproc/unix/procsup.c13 Jan 2002 21:35:16 -
@@ -54,7 +54,7 @@
#include "threadproc.h"
-APR_DECLARE(apr_status_t) apr_proc_detach(void)
+APR_DECLARE(apr_status_t) apr_proc_detach(int dont_fork)
{
int x;
pid_t pgrp;
@@ -63,15 +63,18 @@
#if !defined(MPE) && !defined(OS2) && !defined(TPF) && !defined(BEOS)
/* Don't detach for MPE because child processes can't survive the death of
the parent. */
-if ((x = fork()) > 0)
-exit(0);
-else if (x == -1) {
-perror("fork");
-fprintf(stderr, "unable to fork new process\n");
-exit(1); /* we can't do anything here, so just exit. */
+if (!dont_fork) {
+ if ((x = fork()) > 0)
+ exit(0);
+ else if (x == -1) {
+ perror("fork");
+ fprintf(stderr, "unable to fork new process\n");
+ exit(1); /* we can't do anything here, so just exit. */
+ }
+ /* RAISE_SIGSTOP(DETACH); */
}
-/*RAISE_SIGSTOP(DETACH);*/
#endif
+
#ifdef HAVE_SETSID
if ((pgrp = setsid()) == -1) {
return errno;
--
Jos Backus _/ _/_/_/Santa Clara, CA
_/ _/ _/
_/ _/_/_/
_/ _/ _/_/
[EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: Running Apache in the foreground
On Mon, Jan 07, 2002 at 11:56:28PM -0800, Aaron Bannert wrote: > On Mon, Jan 07, 2002 at 11:51:10PM -0800, Jos Backus wrote: > > On Mon, Jan 07, 2002 at 11:27:53PM -0800, Aaron Bannert wrote: > > > I think we should take the fork() stuff out of apr_proc_detach() > > > instead. Detach is doing what it's supposed to, creating a new session > > > (and therefore detaching from the controlling terminal). The only way > > > it can reliably do that is if it is not a pgrp leader. IMO the way > > > to handle this is to let apr_proc_deatch() assume it is already a > > > non pgrp leader and put the fork() calls that ensure this outside. OK, so we only fork if we are a pgrp leader. Since whether or not to fork is the only thing NO_DETACH controls and since this decision is now to be based on the process' pgrp leader status, it seems that NO_DETACH has become obsolete as we can determine this automatically: when httpd is run by the shell, it's a pgrp leader so we fork; if run by a process controller, it's not a pgrp leader so we don't fork. This would mean that the changes to the current sources amount to: - remove the NO_DETACH/no_detach code - only fork() inside apr_proc_detach() if getpgid() == getpgrp(). How does this sound? > > What about the reopening of fd 0-2 that also happens inside > > apr_proc_detach()? We probably don't want that to happen with NO_DETACH > > (my latest patch fixes this). > > Why not? We redirect to /dev/null and then later reopen stderr to the log > file (and possible stdout to other places, I don't know). Seems reasonable > to me when detaching or not. That was the original NO_DETACH behavior (it didn't call apr_proc_detach() at all). > Not necessarily, since this is a native unix implementation -- we just > have to make sure that getpgid exists on that particular unix. configure doesn't check for getpgid(). Btw, it appears that we use getpgrp() in a number of places already but not getpgid(). Is it OK if I just use getpgrp()? -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: Running Apache in the foreground
On Mon, Jan 07, 2002 at 11:27:53PM -0800, Aaron Bannert wrote: > I think we should take the fork() stuff out of apr_proc_detach() > instead. Detach is doing what it's supposed to, creating a new session > (and therefore detaching from the controlling terminal). The only way > it can reliably do that is if it is not a pgrp leader. IMO the way > to handle this is to let apr_proc_deatch() assume it is already a > non pgrp leader and put the fork() calls that ensure this outside. What about the reopening of fd 0-2 that also happens inside apr_proc_detach()? We probably don't want that to happen with NO_DETACH (my latest patch fixes this). > Another option is to have apr_proc_deatch() simply check if it is > the pgrp leader, and if so to only then call the fork. Wouldn't we need to create a new apr_ function to perform this check because it calls the platform-specific getpgrp()/... functions? I'm assuming that the pgrp leader check simply involves checking if getpgrp() == getpid(). Correct? -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: Running Apache in the foreground
Dec 2001 19:03:48 - 1.33
+++ srclib/apr/threadproc/unix/procsup.c8 Jan 2002 07:36:41 -
@@ -54,24 +54,10 @@
#include "threadproc.h"
-APR_DECLARE(apr_status_t) apr_proc_detach(void)
+APR_DECLARE(apr_status_t) apr_proc_new_sessid(void)
{
-int x;
pid_t pgrp;
-chdir("/");
-#if !defined(MPE) && !defined(OS2) && !defined(TPF) && !defined(BEOS)
-/* Don't detach for MPE because child processes can't survive the death of
- the parent. */
-if ((x = fork()) > 0)
-exit(0);
-else if (x == -1) {
-perror("fork");
-fprintf(stderr, "unable to fork new process\n");
-exit(1); /* we can't do anything here, so just exit. */
-}
-/*RAISE_SIGSTOP(DETACH);*/
-#endif
#ifdef HAVE_SETSID
if ((pgrp = setsid()) == -1) {
return errno;
@@ -91,6 +77,31 @@
return errno;
}
#endif
+
+return APR_SUCCESS;
+}
+
+APR_DECLARE(apr_status_t) apr_proc_detach(void)
+{
+int x;
+
+chdir("/");
+#if !defined(MPE) && !defined(OS2) && !defined(TPF) && !defined(BEOS)
+/* Don't detach for MPE because child processes can't survive the death of
+ the parent. */
+if ((x = fork()) > 0)
+exit(0);
+else if (x == -1) {
+perror("fork");
+fprintf(stderr, "unable to fork new process\n");
+exit(1); /* we can't do anything here, so just exit. */
+}
+/*RAISE_SIGSTOP(DETACH);*/
+#endif
+
+if ((x = apr_proc_new_sessid()) != APR_SUCCESS) {
+return x;
+}
/* close out the standard file descriptors */
if (freopen("/dev/null", "r", stdin) == NULL) {
--
Jos Backus _/ _/_/_/Santa Clara, CA
_/ _/ _/
_/ _/_/_/
_/ _/ _/_/
[EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: Running Apache in the foreground
On Sun, Jan 06, 2002 at 10:28:12PM -0800, Jos Backus wrote:
> On Sun, Jan 06, 2002 at 09:11:11PM -0800, Ryan Bloom wrote:
> > I'm 100% in favor of this stuff, but please just keep using NO_DETACH for
> > this. I didn't get the use case correct for NO_DETACH, but that doesn't
> > mean we should add another option.
>
> Fine with me. This does mean that the NO_DETACH behavior will change (for
> the better, in my view).
Here's the adjusted patch. NO_DETACH now causes apr_proc_detach() to be called
but the fork() skipped. But apr_proc_detach() still reopens std{in,out,err};
this may not be desired behavior. So maybe we should factor out the
setpgid()/setsid() part into its own function (apr_proc_newsessid()?) and call
it instead of apr_proc_detach() when using NO_DETACH? (apr_proc_detach()
would also call this new function.)
Thoughts? Or is this patch good enough?
Index: server/mpm/beos/beos.c
===
RCS file: /home/cvspublic/httpd-2.0/server/mpm/beos/beos.c,v
retrieving revision 1.75
diff -u -r1.75 beos.c
--- server/mpm/beos/beos.c 29 Dec 2001 23:16:23 - 1.75
+++ server/mpm/beos/beos.c 8 Jan 2002 06:44:31 -
@@ -998,7 +998,7 @@
debug = ap_exists_config_define("DEBUG");
if (debug)
-no_detach = one_process = 1;
+no_detach = dont_fork = one_process = 1;
else
{
one_process = ap_exists_config_define("ONE_PROCESS");
@@ -1009,8 +1009,8 @@
if (restart_num++ == 1) {
is_graceful = 0;
-if (!one_process && !no_detach)
- apr_proc_detach();
+if (!one_process)
+ apr_proc_detach(no_detach);
server_pid = getpid();
}
Index: server/mpm/perchild/perchild.c
===
RCS file: /home/cvspublic/httpd-2.0/server/mpm/perchild/perchild.c,v
retrieving revision 1.97
diff -u -r1.97 perchild.c
--- server/mpm/perchild/perchild.c 29 Dec 2001 23:16:23 - 1.97
+++ server/mpm/perchild/perchild.c 8 Jan 2002 06:44:33 -
@@ -1433,9 +1433,8 @@
debug = ap_exists_config_define("DEBUG");
-if (debug) {
+if (debug)
no_detach = one_process = 1;
-}
else {
one_process = ap_exists_config_define("ONE_PROCESS");
no_detach = ap_exists_config_define("NO_DETACH");
@@ -1445,8 +1444,8 @@
if (restart_num++ == 1) {
is_graceful = 0;
-if (!one_process && !no_detach) {
-apr_proc_detach();
+if (!one_process) {
+apr_proc_detach(no_detach);
}
my_pid = getpid();
Index: server/mpm/prefork/prefork.c
===
RCS file: /home/cvspublic/httpd-2.0/server/mpm/prefork/prefork.c,v
retrieving revision 1.227
diff -u -r1.227 prefork.c
--- server/mpm/prefork/prefork.c29 Dec 2001 23:16:24 - 1.227
+++ server/mpm/prefork/prefork.c8 Jan 2002 06:44:34 -
@@ -1216,8 +1216,8 @@
if (restart_num++ == 1) {
is_graceful = 0;
- if (!one_process && !no_detach) {
- apr_proc_detach();
+ if (!one_process) {
+ apr_proc_detach(no_detach);
}
parent_pid = ap_my_pid = getpid();
Index: server/mpm/worker/worker.c
===
RCS file: /home/cvspublic/httpd-2.0/server/mpm/worker/worker.c,v
retrieving revision 1.58
diff -u -r1.58 worker.c
--- server/mpm/worker/worker.c 29 Dec 2001 23:16:24 - 1.58
+++ server/mpm/worker/worker.c 8 Jan 2002 06:44:35 -
@@ -1596,8 +1596,8 @@
if (restart_num++ == 1) {
is_graceful = 0;
-if (!one_process && !no_detach) {
-apr_proc_detach();
+if (!one_process) {
+apr_proc_detach(no_detach);
}
parent_pid = ap_my_pid = getpid();
}
Index: srclib/apr/include/apr_thread_proc.h
===
RCS file: /home/cvspublic/apr/include/apr_thread_proc.h,v
retrieving revision 1.78
diff -u -r1.78 apr_thread_proc.h
--- srclib/apr/include/apr_thread_proc.h27 Dec 2001 17:02:59 - 1.78
+++ srclib/apr/include/apr_thread_proc.h8 Jan 2002 06:44:36 -
@@ -552,7 +552,7 @@
/**
* Detach the process from the controlling terminal.
*/
-APR_DECLARE(apr_status_t) apr_proc_detach(void);
+APR_DECLARE(apr_status_t) apr_proc_detach(int dont_fork);
#if APR_HAS_OTHER_CHILD
Index: srclib/apr/threadproc/netware/proc.c
===
RCS file: /home/cvspublic/apr/threadproc/netware/proc.c,v
retrieving revision 1.3
diff -u -r1.3 proc.c
--- srclib/apr/threadproc/netware/proc.c23 Oct 2001 17:30:08 - 1.3
+++ srclib/ap
Re: Running Apache in the foreground
On Sun, Jan 06, 2002 at 09:11:11PM -0800, Ryan Bloom wrote: > I'm 100% in favor of this stuff, but please just keep using NO_DETACH for > this. I didn't get the use case correct for NO_DETACH, but that doesn't mean > we should add another option. Fine with me. This does mean that the NO_DETACH behavior will change (for the better, in my view). -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: Running Apache in the foreground
On Fri, Jan 04, 2002 at 11:52:26PM -0800, Jos Backus wrote: > On Fri, Jan 04, 2002 at 09:26:46PM -0800, Justin Erenkrantz wrote: > > Yeah, this seems to be a bug in autoconf because this is not > > portable /bin/sh code. IIRC, all cases must have an action item. I misread this (shame on me), sorry. POSIX agrees: > POSIX 1003.1 says: > > The format for the case construct is as follows: > > case word in > [(] pattern1) compound-list;; > [[(] pattern[ | pattern] ... ) compound-list;;] ... > [[(] pattern[ | pattern] ... ) compound-list] > esac zsh and bash are simply more forgiving (or don't spot the error, if you will). -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: Running Apache in the foreground
On Fri, Jan 04, 2002 at 09:26:46PM -0800, Justin Erenkrantz wrote: > Yeah, this seems to be a bug in autoconf because this is not > portable /bin/sh code. IIRC, all cases must have an action item. OK. > Are you using 2.52? I can't see any way around this besides > getting the autoconf people to fix this. Yes, I am using 2.52. > HTH. From my cursory examination of 2.52f, it seems like > it has the same problem. But, my /bin/sh is happy with the > empty case statements. So, I can't reproduce this. -- justin zsh and bash have no problems with them either, both manpages list the pattern) list;; parts as optional, unlike FreeBSD's sh. Is your sh bash by any chance? POSIX 1003.1 says: The format for the case construct is as follows: case word in [(] pattern1) compound-list;; [[(] pattern[ | pattern] ... ) compound-list;;] ... [[(] pattern[ | pattern] ... ) compound-list] esac The ";;" is optional for the last compound-list. I'll notify the FreeBSD crowd. Thanks Justin. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: Running Apache in the foreground
+ exit(1); /* we can't do anything here, so just exit. */
+ }
+/*RAISE_SIGSTOP(DETACH);*/
}
-/*RAISE_SIGSTOP(DETACH);*/
#endif
#if APR_HAVE_SETSID
if ((pgrp = setsid()) == -1) {
Index: srclib/apr/threadproc/os2/proc.c
===
RCS file: /home/cvspublic/apr/threadproc/os2/proc.c,v
retrieving revision 1.47
diff -u -r1.47 proc.c
--- srclib/apr/threadproc/os2/proc.c26 Oct 2001 02:31:04 - 1.47
+++ srclib/apr/threadproc/os2/proc.c5 Jan 2002 05:07:19 -
@@ -620,7 +620,7 @@
-APR_DECLARE(apr_status_t) apr_proc_detach()
+APR_DECLARE(apr_status_t) apr_proc_detach(int dont_fork)
{
return APR_ENOTIMPL;
}
Index: srclib/apr/threadproc/unix/proc.c
===
RCS file: /home/cvspublic/apr/threadproc/unix/proc.c,v
retrieving revision 1.53
diff -u -r1.53 proc.c
--- srclib/apr/threadproc/unix/proc.c 11 Nov 2001 05:51:00 - 1.53
+++ srclib/apr/threadproc/unix/proc.c 5 Jan 2002 05:07:19 -
@@ -362,13 +362,13 @@
}
newargs[i + 2] = NULL;
if (attr->detached) {
-apr_proc_detach();
+apr_proc_detach(0);
}
execve(SHELL_PATH, (char * const *) newargs, (char * const *)env);
}
else {
if (attr->detached) {
-apr_proc_detach();
+apr_proc_detach(0);
}
execve(progname, (char * const *)args, (char * const *)env);
}
Index: srclib/apr/threadproc/unix/procsup.c
===
RCS file: /home/cvspublic/apr/threadproc/unix/procsup.c,v
retrieving revision 1.33
diff -u -r1.33 procsup.c
--- srclib/apr/threadproc/unix/procsup.c28 Dec 2001 19:03:48 - 1.33
+++ srclib/apr/threadproc/unix/procsup.c5 Jan 2002 05:07:19 -
@@ -54,7 +54,7 @@
#include "threadproc.h"
-APR_DECLARE(apr_status_t) apr_proc_detach(void)
+APR_DECLARE(apr_status_t) apr_proc_detach(int dont_fork)
{
int x;
pid_t pgrp;
@@ -63,14 +63,16 @@
#if !defined(MPE) && !defined(OS2) && !defined(TPF) && !defined(BEOS)
/* Don't detach for MPE because child processes can't survive the death of
the parent. */
-if ((x = fork()) > 0)
-exit(0);
-else if (x == -1) {
-perror("fork");
- fprintf(stderr, "unable to fork new process\n");
-exit(1); /* we can't do anything here, so just exit. */
+if (!dont_fork) {
+ if ((x = fork()) > 0)
+ exit(0);
+ else if (x == -1) {
+ perror("fork");
+ fprintf(stderr, "unable to fork new process\n");
+ exit(1); /* we can't do anything here, so just exit. */
+ }
+/*RAISE_SIGSTOP(DETACH);*/
}
-/*RAISE_SIGSTOP(DETACH);*/
#endif
#ifdef HAVE_SETSID
if ((pgrp = setsid()) == -1) {
--
Jos Backus _/ _/_/_/Santa Clara, CA
_/ _/ _/
_/ _/_/_/
_/ _/ _/_/
[EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: Running Apache in the foreground
defined(TPF) && !defined(BEOS)
/* Don't detach for MPE because child processes can't survive the death of
the parent. */
-if ((x = fork()) > 0)
-exit(0);
-else if (x == -1) {
-perror("fork");
-fprintf(stderr, "unable to fork new process\n");
-exit(1); /* we can't do anything here, so just exit. */
+if (!dont_fork) {
+ if ((x = fork()) > 0)
+ exit(0);
+ else if (x == -1) {
+ perror("fork");
+ fprintf(stderr, "unable to fork new process\n");
+ exit(1); /* we can't do anything here, so just exit. */
+ }
+/*RAISE_SIGSTOP(DETACH);*/
}
-/*RAISE_SIGSTOP(DETACH);*/
#endif
#if APR_HAVE_SETSID
if ((pgrp = setsid()) == -1) {
--
Jos Backus _/ _/_/_/Santa Clara, CA
_/ _/ _/
_/ _/_/_/
_/ _/ _/_/
[EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: Running Apache in the foreground
On Fri, Dec 28, 2001 at 11:38:01PM -0800, Jos Backus wrote: [massive snippage] > So I am really hoping that the Samba people will adopt my patch :-) Update: Jeremy Allison has committed a variation of my patch to the Samba tree. See http://cvs.samba.org/cgi-bin/cvsweb/samba/source/smbd/server.c.diff?r1=1.350&r2=1.351&f=h -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: connections are hanging for 2.0 cvs on Cygwin 1.x (worker mpm)
On Sat, Dec 29, 2001 at 11:49:10AM -0800, Justin Erenkrantz wrote: > The problem is there is no debug tools on FreeBSD that can follow > forks, so I have no idea what is going on. kdump is the only > thing I can find and it is too low-level to show any lock calls > (which is where I think the problem is). What about the -d and -i flags of ktrace? I use those all the time and I am running -current. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: Running Apache in the foreground
On Fri, Dec 28, 2001 at 05:46:58PM -0800, Aaron Bannert wrote: > On Fri, Dec 28, 2001 at 01:16:56PM -0801, Jos Backus wrote: > > 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. Thank you, I will. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: Running Apache in the foreground
On Fri, Dec 28, 2001 at 05:46:58PM -0800, Aaron Bannert wrote: > 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). This must be the fork that happens in svscan (see my previous e-mail). > 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. Unfortunately I don't really know the Apache code that well yet, sorry :-/ Hopefully somebody else will have some good ideas... > 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. Indeed. That is what (in the daemontools case - my AIX is rusty) svscan/supervise do. See my previous e-mail. > > 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. The svscan.c and supervise.c sources only contain a couple of fork() calls, so that must be sufficient. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: Running Apache in the foreground
On Fri, Dec 28, 2001 at 05:35:13PM -0800, Aaron Bannert wrote:
> On Fri, Dec 28, 2001 at 05:03:06PM -0800, Jos Backus wrote:
> > Interestingly in the Samba code the setsid() call comes _after_ the fork()
> > (see my previous e-mail) and that seems to work just fine. So it looks like
> > the order suggested is not an absolute requirement; any thoughts on this?
>
> Let me clarify a little:
>
> setsid() MUST be called by a proces that is NOT a process group leader,
> else it will fail with -1.
Yes.
> Apache is normally started in two ways:
> 1) bin/apachectl
> 2) bin/httpd
>
> Normally when starting a program from the shell, that program becomes the
> process group leader of a new process group. In case #1 the apachectl
> script becomes the process leader and httpd becomes it's child (which
> will inherit the PGID). This means httpd is NOT a process group leader. In
> case #2, httpd IS the process group leader, and hence setsid() will fail.
Yes. In the daemontools case, the supervise program forks and its child runs
the ``run'' script, which in turn execs the daemon. So I'm assuming that the
daemon is _not_ the pgrp leader. Consider this evidence: on my FreeBSD
-current system I see the following:
% ps -ax -o pid,ppid,pgid,command
246 146 svscan /service
273 24646 supervise nmbd
282 24646 supervise smbd
22124 273 22124 /usr/local/sbin/nmbd -F
22127 22124 22124 /usr/local/sbin/nmbd -F
22125 282 22125 /usr/local/sbin/smbd -F
The ``run'' script (for nmbd) is simply
#!/bin/sh
exec /usr/local/sbin/nmbd -F
The above output clearly shows {n,s}mbd running in their own pgrps, which is
what we want; when I down those services using ``svc -d /service/?mbd'' they
go away, without killing the members of pgrp 46. Without the -F flag/patch all
the members of pgrp 46 do get killed, which is obviously undesirable. So I am
really hoping that the Samba people will adopt my patch :-)
> Therefore the only way to ensure that the calling process is NOT the
> process group leader is to call fork() before calling setsid().
I understand. Surely there is a way to make this work with httpd also?
And thank you for the clarification.
--
Jos Backus _/ _/_/_/Santa Clara, CA
_/ _/ _/
_/ _/_/_/
_/ _/ _/_/
[EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: Running Apache in the foreground
On Fri, Dec 28, 2001 at 01:31:04AM -0800, Justin Erenkrantz wrote: > 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 As I stated in my previous mail, I misunderstood this, my bad, sorry for the false alert. Interestingly in the Samba code the setsid() call comes _after_ the fork() (see my previous e-mail) and that seems to work just fine. So it looks like the order suggested is not an absolute requirement; any thoughts on this? -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: Running Apache in the foreground
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
#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
_/ _/ _/
_/ _/_/_/
_/ _/ _/_/
[EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: Running Apache in the foreground
[Cc'd the FreeBSD Apache2 port committer because he may be interested in this
discussion.]
Hi Justin,
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:
lizzy:/usr/ports/www/apache2/work/httpd-2_0_28# diff -u ./srclib/apr/threadproc/
unix/procsup.c.orig ./srclib/apr/threadproc/unix/procsup.c
--- ./srclib/apr/threadproc/unix/procsup.c.orig Fri Dec 28 00:39:58 2001
+++ ./srclib/apr/threadproc/unix/procsup.c Fri Dec 28 00:40:59 2001
@@ -54,7 +54,7 @@
#include "threadproc.h"
-APR_DECLARE(apr_status_t) apr_proc_detach(void)
+APR_DECLARE(apr_status_t) apr_proc_detach(int dont_fork)
{
int x;
pid_t pgrp;
@@ -63,13 +63,14 @@
#if !defined(MPE) && !defined(OS2) && !defined(TPF) && !defined(BEOS)
/* Don't detach for MPE because child processes can't survive the death of
the parent. */
-if ((x = fork()) > 0)
-exit(0);
-else if (x == -1) {
-perror("fork");
-fprintf(stderr, "unable to fork new process\n");
-exit(1); /* we can't do anything here, so just exit. */
-}
+if (!dont_fork)
+ if ((x = fork()) > 0)
+ exit(0);
+ else if (x == -1) {
+ perror("fork");
+ fprintf(stderr, "unable to fork new process\n");
+ exit(1); /* we can't do anything here, so just exit. */
+ }
/*RAISE_SIGSTOP(DETACH);*/
#endif
#if APR_HAVE_SETSID
Of course, all the callers of apr_proc_detach() would need to be modified
(easy) and a new -D option would need to be implemented which causes this
behavior. This would make Apache play nice with AIX's System Resource
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.
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. 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.
Btw, I reported this problem earlier in a mail to apache-dev (Subject:
HAVE_SETSID problem, date: Thu, 27 Dec 2001 17:44:22 -0800)
> Do you have a better mechanism in mind?
See above, hope that explains things well enough.
> 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.
Thank you!
--
Jos Backus _/ _/_/_/Santa Clara, CA
_/ _/ _/
_/ _/_/_/
_/ _/ _/_/
[EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Running Apache in the foreground
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). That is, if there is any interest. A previous bugreport in this area was ignored so I may be wasting my time. I'll interpret no response as ``no interest, go away''. Thanks, -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
HAVE_SETSID problem
I am trying to modify Apache 2.0.28 to put itself into its own pgrp even when
using NO_DETACH, and am seeing something strange. include/ap_config_auto.h
uses HAVE_SETSID, but srclib/apr/threadproc/unix/procsup.c checks for
APR_HAVE_SETSID. So on FreeBSD, even though HAVE_SETSID is set, the code in
procsup.c uses setpgid() instead of setsid(), which seems wrong to me. Also,
in the code that does get used, pgrp gets set to 0, which doesn't make much
sense to me (but maybe I misunderstand how setpgid() works).
if ((pgrp = setpgid(0, 0)) == -1) {
return errno;
}
Ideas, anyone?
Thanks,
--
Jos Backus _/ _/_/_/Santa Clara, CA
_/ _/ _/
_/ _/_/_/
_/ _/ _/_/
[EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
