Re: Running Apache in the foreground
Excellent news, thank you all for your hard work on this! Now that we have this feature in 2.0, can we also backport it into the 1.3.* tree, for completeness sake? I've attached a patch for 1.3.23, which is an updating of my patch for 1.3.22. The patch is also available at: http://www.sub-rosa.com/handler/pub/apache-1.3.23-foreground-patch --michael Aaron Bannert <[EMAIL PROTECTED]> writes: > 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). 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 for the original patch! I just committed the last chunk from > the patch I posted last week, so we should be good to go. > > -aaron -- [EMAIL PROTECTED] (michael handler) washington, dc --- http_main.c.distThu Feb 21 16:57:02 2002 +++ http_main.c Thu Feb 21 17:02:28 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. */ @@ -1346,7 +1348,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); @@ -1354,7 +1356,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"); @@ -1376,6 +1378,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"); @@ -3365,14 +3368,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) { @@ -5292,7 +5297,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 @@ -5314,6 +5319,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; @@ -7190,9 +7198,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:vVlLsStTh")) != -1) { +while ((c = getopt(argc, argv, "D:C:c:Xd:Ff:vVlLsStTh")) != -1) { #endif char **new; switch (c) { @@ -7301,6 +7309,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': ap_cpy
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
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). 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 for the original patch! I just committed the last chunk from the patch I posted last week, so we should be good to go. -aaron
Re: Running Apache in the foreground
On Thu, Feb 14, 2002 at 03:01:11PM -0800, Aaron Bannert wrote: > Basicly what we have now is the following flags: > > -DNO_DETACH - assume we are not the process group leader, just create > a new session (or pgrp if setsid() is not supported). > This detaches us from the controlling terminal. > [We don't "daemonize" so that process watchers can keep >track of us directly.] > > -DONE_PROCESS - enables NO_DETACH, only runs one process in a multiprocess MPM > > - same as NO_DETACH, only we always fork() before creating > a new session. In APR I've called this "to daemonize". +1. This is a long time coming. -- justin
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
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). 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''. Hi Jos, This patch is a long time comming, but I think it's ready. I'd had to add error return values to the pre_config hook and fix some other signal-related bugs before this patch could be applied, but I think it's ready. Test it and give it your blessing. It is almost identical to the original patch you submitted, only that I flipped the polarity and the name of the new apr_proc_detach parameter from "dont_fork" to "daemonize", and then made the values #defined. Basicly what we have now is the following flags: -DNO_DETACH - assume we are not the process group leader, just create a new session (or pgrp if setsid() is not supported). This detaches us from the controlling terminal. [We don't "daemonize" so that process watchers can keep track of us directly.] -DONE_PROCESS - enables NO_DETACH, only runs one process in a multiprocess MPM - same as NO_DETACH, only we always fork() before creating a new session. In APR I've called this "to daemonize". -aaron Index: server/mpm/beos/beos.c === RCS file: /home/cvs/httpd-2.0/server/mpm/beos/beos.c,v retrieving revision 1.83 diff -u -r1.83 beos.c --- server/mpm/beos/beos.c 1 Feb 2002 22:16:31 - 1.83 +++ server/mpm/beos/beos.c 14 Feb 2002 22:51:14 - @@ -1012,8 +1012,9 @@ if (restart_num++ == 1) { is_graceful = 0; -if (!one_process && !no_detach) { - rv = apr_proc_detach(); +if (!one_process) { +rv = apr_proc_detach(no_detach ? APR_PROC_DETACH_FOREGROUND + : APR_PROC_DETACH_DAEMONIZE); if (rv != APR_SUCCESS) { ap_log_error(APLOG_MARK, APLOG_CRIT, rv, NULL, "apr_proc_detach failed"); Index: server/mpm/perchild/perchild.c === RCS file: /home/cvs/httpd-2.0/server/mpm/perchild/perchild.c,v retrieving revision 1.108 diff -u -r1.108 perchild.c --- server/mpm/perchild/perchild.c 5 Feb 2002 22:18:49 - 1.108 +++ server/mpm/perchild/perchild.c 14 Feb 2002 22:51:17 - @@ -1473,8 +1473,9 @@ if (restart_num++ == 1) { is_graceful = 0; -if (!one_process && !no_detach) { -rv = apr_proc_detach(); +if (!one_process) { +rv = apr_proc_detach(no_detach ? APR_PROC_DETACH_FOREGROUND + : APR_PROC_DETACH_DAEMONIZE); if (rv != APR_SUCCESS) { ap_log_error(APLOG_MARK, APLOG_CRIT, rv, NULL, "apr_proc_detach failed"); Index: server/mpm/prefork/prefork.c === RCS file: /home/cvs/httpd-2.0/server/mpm/prefork/prefork.c,v retrieving revision 1.241 diff -u -r1.241 prefork.c --- server/mpm/prefork/prefork.c11 Feb 2002 23:20:15 - 1.241 +++ server/mpm/prefork/prefork.c14 Feb 2002 22:51:17 - @@ -1235,8 +1235,9 @@ if (restart_num++ == 1) { is_graceful = 0; -if (!one_process && !no_detach) { -rv = apr_proc_detach(); +if (!one_process) { +rv = apr_proc_detach(no_detach ? APR_PROC_DETACH_FOREGROUND + : APR_PROC_DETACH_DAEMONIZE); if (rv != APR_SUCCESS) { ap_log_error(APLOG_MARK, APLOG_CRIT, rv, NULL, "apr_proc_detach failed"); Index: server/mpm/worker/worker.c === RCS file: /home/cvs/httpd-2.0/server/mpm/worker/worker.c,v retrieving revision 1.76 diff -u -r1.76 worker.c --- server/mpm/worker/worker.c 14 Feb 2002 02:48:19 - 1.76 +++ server/mpm/worker/worker.c 14 Feb 2002 22:51:19 - @@ -1544,17 +1544,17 @@ } } else if (!max_clients -&& strncasecmp(pdir->directive, "MaxClients", 10) == 0) { + && strncasecmp(pdir->directive, "MaxClients", 10) == 0) { max_clients = pdir; } } debug = ap_exists_config_define("DEBUG"); -if (debug) +if (debug) { no_detach = one_process = 1; -else -{ +} +else { one_process = ap_exists_config_define("ONE_PROCESS"); no_detach = ap_exists_config_define("NO_DETACH"); } @@ -1563,8 +1563,9 @@ if (restart_num++ == 1) {
Re: Running Apache in the foreground
On Sun, Jan 13, 2002 at 01:38:56PM -0801, Jos Backus wrote: > Based on Michael Handler's feedback, here's another patch which simply fixes > -DNO_DETACH to dtrt. This way things are under operator control and we avoid > people running httpd under non-job-control shells shooting themselves in the > foot. > > Please let me know if there's anything that prevents this patch from being > incorporated so I can fix it. Thanks! As a rule, please don't do style changes in a patch that changes functionality. It makes it too hard to review what you have really changed. > @@ -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"); This and others like it is a no-no. The current style is correct (brace even if one-line) - we do this to make it easier when people add a line to a conditional clause. (I learned this the hard way, too...) Please remove any unnecessary style changes and resubmit your patch. Thanks. -- justin
Re: Running Apache in the foreground
Based on Michael Handler's feedback, here's another patch which simply fixes -DNO_DETACH to dtrt. This way things are under operator control and we avoid people running httpd under non-job-control shells shooting themselves in the foot. Please let me know if there's anything that prevents this patch from being incorporated so I can fix it. Thanks! Index: server/mpm/beos/beos.c === RCS file: /home/cvspublic/httpd-2.0/server/mpm/beos/beos.c,v retrieving revision 1.76 diff -u -r1.76 beos.c --- server/mpm/beos/beos.c 10 Jan 2002 00:27:58 - 1.76 +++ server/mpm/beos/beos.c 13 Jan 2002 21:35:08 - @@ -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.98 diff -u -r1.98 perchild.c --- server/mpm/perchild/perchild.c 10 Jan 2002 00:27:59 - 1.98 +++ server/mpm/perchild/perchild.c 13 Jan 2002 21:35:10 - @@ -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,9 +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.229 diff -u -r1.229 prefork.c --- server/mpm/prefork/prefork.c11 Jan 2002 14:13:23 - 1.229 +++ server/mpm/prefork/prefork.c13 Jan 2002 21:35:11 - @@ -1217,9 +1217,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.60 diff -u -r1.60 worker.c --- server/mpm/worker/worker.c 11 Jan 2002 08:01:11 - 1.60 +++ server/mpm/worker/worker.c 13 Jan 2002 21:35:13 - @@ -1596,9 +1596,9 @@ 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.h13 Jan 2002 21:35:14 - @@ -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.4 diff -u -r1.4 proc.c --- srclib/apr/threadproc/netware/proc.c8 Jan 2002 21:00:37 - 1.4 +++ srclib/apr/threadproc/netware/proc.c13 Jan 2002 21:35:15 - @@ -345,13 +345,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/netware/procsup.c === RCS file: /home/cvspublic/apr/threadproc/netware/procsup.c,v retrieving revision 1.1 diff -u -r1.1 procsup.c --- srclib/apr/threadproc/netware/procsup.c 2 Aug 2001 20:29:14 - 1.1 +++ srclib/apr/threadproc/n
Re: Running Apache in the foreground
Jos Backus <[EMAIL PROTECTED]> writes: > 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 assumption is dangerous and incorrect. You're overlooking the interaction between sessions, process groups, and shells with and without job control. httpd calls setsid(2) not only to create a new process group and become its leader, but to escape the current session and controlling terminal. setsid(2) has to be called regardless of whether we want the main httpd to double-fork away from its parent, to get away from the controlling terminal. You can't call setsid(2) if you're already process group leader. However, when you invoke httpd under a shell with job control (e.g. bash), it is automatically put into a new process group as the leader: Starting under Solaris /bin/sh without job control: # ps -o uid,pid,ppid,pgid,sid,comm UID PID PPID PGID SID COMMAND 0 20240 20238 20240 20240 -sh 0 20255 20240 20240 20240 ps # ./test pid = 20256, pgrp = 20240, sid = 20240 We're a member of the parent shell's process group, but not the leader, and thus can setsid(2). Starting under bash with job control: # bash root@build1:~# ps -o uid,pid,ppid,pgid,sid,comm UID PID PPID PGID SID COMMAND 0 20251 20250 20251 20240 ps 0 20240 20238 20240 20240 -sh 0 20250 20240 20250 20240 bash root@build1:~# ./test pid = 20252, pgrp = 20252, sid = 20240 We're a member of our OWN process group AND the leader, and thus can't setsid(2). This is the reason that httpd forks before calling setsid(2) -- so that in case it was run under a shell with job control and was made process group leader, it's not process group leader anymore, because its parent is, or rather was, before it exited). [1] Thus, if httpd is started from a shell with job control, it MUST fork(2) at least once before calling setsid(2). Note that this means that our non-forking process supervisor mode for httpd will never work if httpd is invoked from a shell with job control. I think this is a reasonable restriction, as long as it's properly noted in the documentation. Now, Jos' assumption above is dangerous because if you're invoked from a system startup script that runs under a shell without job control, e.g. Solaris /bin/sh, you're not going to be process group leader. Under the logic above, it wouldn't daemonize, and the system startup script would never exit, and system startup would hang forever. (Hope you started sshd before httpd. :)) I don't believe that there's any portable or reliable way for httpd to detect whether whether it's being run under a 'process controller' or not. As I've just shown above, whether it's a process group leader already is not reliable. Thus, we need to make httpd have a normal mode (daemonize), with a command line switch to disable this behavior (-DWHATEVER) if a sysadmin wants to run httpd under a process controller. I also wouldn't mind if someone took a look at my patch for apache 1.3.22 to accomplish this same issue. :) http://bugs.apache.org/index.cgi/full/9341 Thanks for your consideration. --michael [1] Stevens, _Unix Network Programming, Volume One_ (2nd Edition), pp 335: "We first call fork(2) and then the parent terminates and the child continues. [...] Also, the child inherits the process group ID from the parent but gets its own process ID. This guarantees that the child is not a process group leader, which is required for the next call to setsid(2)." -- [EMAIL PROTECTED] (michael handler) washington, dc
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: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. > > 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. > > 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? Not necessarily, since this is a native unix implementation -- we just have to make sure that getpgid exists on that particular unix. > I'm assuming that the > pgrp leader check simply involves checking if getpgrp() == getpid(). Correct? Yes, that's how I understand it. -aaron
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
On Mon, Jan 07, 2002 at 10:54:48PM -0800, Justin Erenkrantz wrote: > Precisely my thoughts. IMHO, split it out. (The name is a bit > iffy, but we can work on that...) -- justin Suggestions for a better name welcome :) Patch below. Btw, it appears that the current code in CVS does not build on FreeBSD -current: /bin/sh /home/jos/src/apache2/httpd-2.0/srclib/apr/libtool --silent --mode=compile gcc -g -O2 -DHAVE_CONFIG_H -D_REENTRANT -D_THREAD_SAFE -I/home/jos/src/apache2/httpd-2.0/srclib/apr-util/include -I/home/jos/src/apache2/httpd-2.0/srclib/apr-util/include -I/home/jos/src/apache2/httpd-2.0/srclib/apr/include -c apr_rmm.c && touch apr_rmm.lo In file included from /home/jos/src/apache2/httpd-2.0/srclib/apr-util/include/apr_rmm.h:71, from apr_rmm.c:56: /home/jos/src/apache2/httpd-2.0/srclib/apr-util/include/apr_anylock.h:76: syntax error before `apr_thread_mutex_t' apr_rmm.c: In function `apr_rmm_init': apr_rmm.c:216: union has no member named `rw' apr_rmm.c:219: union has no member named `tm' apr_rmm.c:219: union has no member named `rw' apr_rmm.c:219: union has no member named `rw' apr_rmm.c:238: union has no member named `tm' apr_rmm.c:238: union has no member named `rw' apr_rmm.c: In function `apr_rmm_destroy': apr_rmm.c:247: union has no member named `tm' apr_rmm.c:247: union has no member named `rw' apr_rmm.c:247: union has no member named `rw' apr_rmm.c:272: union has no member named `tm' apr_rmm.c:272: union has no member named `rw' apr_rmm.c: In function `apr_rmm_attach': apr_rmm.c:283: union has no member named `rw' apr_rmm.c: In function `apr_rmm_malloc': apr_rmm.c:307: union has no member named `tm' apr_rmm.c:307: union has no member named `rw' apr_rmm.c:307: union has no member named `rw' apr_rmm.c:317: union has no member named `tm' apr_rmm.c:317: union has no member named `rw' apr_rmm.c: In function `apr_rmm_calloc': apr_rmm.c:326: union has no member named `tm' apr_rmm.c:326: union has no member named `rw' apr_rmm.c:326: union has no member named `rw' apr_rmm.c:337: union has no member named `tm' apr_rmm.c:337: union has no member named `rw' apr_rmm.c: In function `apr_rmm_free': apr_rmm.c:357: union has no member named `tm' apr_rmm.c:357: union has no member named `rw' apr_rmm.c:357: union has no member named `rw' apr_rmm.c:363: union has no member named `tm' apr_rmm.c:363: union has no member named `rw' apr_rmm.c:369: union has no member named `tm' apr_rmm.c:369: union has no member named `rw' apr_rmm.c:377: union has no member named `tm' apr_rmm.c:377: union has no member named `rw' apr_rmm.c:386: union has no member named `tm' apr_rmm.c:386: union has no member named `rw' *** Error code 1 Stop in /home/jos/src/apache2/httpd-2.0/srclib/apr-util/misc. *** Error code 1 Stop in /home/jos/src/apache2/httpd-2.0/srclib/apr-util/misc. *** Error code 1 Stop in /home/jos/src/apache2/httpd-2.0/srclib/apr-util. *** Error code 1 Stop in /home/jos/src/apache2/httpd-2.0/srclib. *** Error code 1 Stop in /home/jos/src/apache2/httpd-2.0. 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 07:36:34 - @@ -1009,8 +1009,11 @@ if (restart_num++ == 1) { is_graceful = 0; -if (!one_process && !no_detach) - apr_proc_detach(); +if (!one_process) + if (no_detach) + apr_proc_new_sessid(); + else + apr_proc_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 07:36:36 - @@ -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,9 +1444,11 @@ if (restart_num++ == 1) { is_graceful = 0; -if (!one_process && !no_detach) { -apr_proc_detach(); -} +if (!one_process) + if (no_detach) + apr_proc_new_sessid(); + else + apr_proc_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 200
Re: Running Apache in the foreground
On Mon, Jan 07, 2002 at 10:54:48PM -0800, Justin Erenkrantz wrote: > On Mon, Jan 07, 2002 at 10:53:00PM -0800, Jos Backus wrote: > > 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.) > > Precisely my thoughts. IMHO, split it out. (The name is a bit > iffy, but we can work on that...) -- justin 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. 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. -aaron
Re: Running Apache in the foreground
On Mon, Jan 07, 2002 at 10:53:00PM -0800, Jos Backus wrote: > 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.) Precisely my thoughts. IMHO, split it out. (The name is a bit iffy, but we can work on that...) -- justin
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/apr/threadproc/netware/proc.c8 Jan 2002 06:44:37 - @@ -345,13 +345,13 @@ } newargs[i + 2] = NULL;
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 Friday 04 January 2002 03:59 pm, Jos Backus wrote: > On Thu, Jan 03, 2002 at 08:28:14AM -0800, Aaron Bannert wrote: > > I see no reason why this can't be implemented in apache2, and I'll > > even test and commit a patch that properly implements it. :) Sorry > > I can't offer much more than that. Maybe if I get some more time > > later this week I can look into it, but the more surefire way to get > > it in would be to provide a patch. > > Here's a patch that appears to dtrt. I chose DONT_FORK as the keyword but I > would happily change this or any other name to something else, just let me > know. The main thing is that the patch goes in :-) Btw, the patch is against > 2.0.28, I hope that is not too big of a problem; I can look into bringing it > up to HEAD if desired. 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. Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: Running Apache in the foreground
On Sat, 5 Jan 2002, Jos Backus wrote: > 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: The issue came up in this forum a couple of months ago already, when autoconf-2.50 was released. If someone has the necessary time, please try to fix autoconf and submit a patch to the authors. - Sascha Experience IRCG http://schumann.cx/http://schumann.cx/ircg
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
On Fri, Jan 04, 2002 at 09:13:51PM -0801, Jos Backus wrote: > Fyi, as an aside, when building from CVS I am seeing > > ./config.status: 765: Syntax error: "done" unexpected (expecting ")") > > The script: > > # > # CONFIG_COMMANDS section. > # > for ac_file in : $CONFIG_COMMANDS; do test "x$ac_file" = x: && continue > ac_dest=`echo "$ac_file" | sed 's,:.*,,'` > ac_source=`echo "$ac_file" | sed 's,[^:]*:,,'` > > case $ac_dest in<- line 765 > esac > done > > { (exit 0); exit 0; } 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. Are you using 2.52? I can't see any way around this besides getting the autoconf people to fix this. You *could* try upgrading to autoconf-2.52f: ftp://alpha.gnu.org/gnu/autoconf/autoconf-2.52f.tar.bz2 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
Re: Running Apache in the foreground
Fyi, as an aside, when building from CVS I am seeing ./config.status: 765: Syntax error: "done" unexpected (expecting ")") The script: # # CONFIG_COMMANDS section. # for ac_file in : $CONFIG_COMMANDS; do test "x$ac_file" = x: && continue ac_dest=`echo "$ac_file" | sed 's,:.*,,'` ac_source=`echo "$ac_file" | sed 's,[^:]*:,,'` case $ac_dest in <- line 765 esac done { (exit 0); exit 0; } On Fri, Jan 04, 2002 at 04:42:24PM -0800, Aaron Bannert wrote: > A couple things: > > This looks good in concept. Thanks! > This will have to apply to HEAD cleanly, so please modify/test/repost. See below. I have changed the flag to NEW_SESSID for now. I have kept the dont_fork variable name because because it describes exactly what it does. Also, when debug is set, I now set dont_fork to 1. Comments? > I'm not sure I like overloading the use of apr_proc_detach, and I'd prefer > to see us come up with another function. I'm open to suggestions here. > Maybe apr_proc_detach can only fork if it detects we are the process > group leader? I guess I could implement that, if that's the way we want to go. > Another option would be to move the fork() out of apr_proc_detach() > entirely. Yes. > DONT_FORK is misleading, since we're still going to fork() in other > places, just not in the parent process and with the sole purpose of > killing off the original parent. Any reason why this isn't just NEW_SESSID > or something akin to that? Sure, renamed accordingly. > Given this patch I don't really see the purpose of NO_DETACH anymore, so > maybe we could just steal that name? Sounds good, but I'm not sure if it is a drop-in replacement. Are you thinking of changing if (!one_process && !no_detach) { apr_proc_detach(new_sessid); } to if (!one_process) { apr_proc_detach(!no_detach); } ? 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 5 Jan 2002 05:07:12 - @@ -993,16 +993,17 @@ static void beos_pre_config(apr_pool_t *pconf, apr_pool_t *plog, apr_pool_t *ptemp) { static int restart_num = 0; -int no_detach, debug; +int no_detach, dont_fork, debug; 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"); no_detach = ap_exists_config_define("NO_DETACH"); +dont_fork = ap_exists_config_define("NEW_SESSID"); } /* sigh, want this only the second time around */ @@ -1010,7 +1011,7 @@ is_graceful = 0; if (!one_process && !no_detach) - apr_proc_detach(); + apr_proc_detach(dont_fork); 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 5 Jan 2002 05:07:14 - @@ -1425,7 +1425,7 @@ static void perchild_pre_config(apr_pool_t *p, apr_pool_t *plog, apr_pool_t *ptemp) { static int restart_num = 0; -int no_detach, debug; +int no_detach, dont_fork, debug; ap_directive_t *pdir; int i; int tmp_server_limit = DEFAULT_SERVER_LIMIT; @@ -1433,12 +1433,12 @@ debug = ap_exists_config_define("DEBUG"); -if (debug) { -no_detach = one_process = 1; -} +if (debug) +no_detach = dont_fork = one_process = 1; else { one_process = ap_exists_config_define("ONE_PROCESS"); no_detach = ap_exists_config_define("NO_DETACH"); +dont_fork = ap_exists_config_define("NEW_SESSID"); } /* sigh, want this only the second time around */ @@ -1446,7 +1446,7 @@ is_graceful = 0; if (!one_process && !no_detach) { -apr_proc_detach(); +apr_proc_detach(dont_fork); } 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.c5 Jan 2002 05:07:15 - @@ -1200,16 +1200,17 @@ static void prefork_pre_config(apr_pool_t *p, apr_pool_t *plog, apr_pool_t *ptemp) { static int restart_num = 0; -int no_detach, debug; +int no_detach,
Re: Running Apache in the foreground
On Fri, Jan 04, 2002 at 03:59:24PM -0800, Jos Backus wrote: > On Thu, Jan 03, 2002 at 08:28:14AM -0800, Aaron Bannert wrote: > > I see no reason why this can't be implemented in apache2, and I'll > > even test and commit a patch that properly implements it. :) Sorry > > I can't offer much more than that. Maybe if I get some more time > > later this week I can look into it, but the more surefire way to get > > it in would be to provide a patch. > > Here's a patch that appears to dtrt. I chose DONT_FORK as the keyword but I > would happily change this or any other name to something else, just let me > know. The main thing is that the patch goes in :-) Btw, the patch is against > 2.0.28, I hope that is not too big of a problem; I can look into bringing it > up to HEAD if desired. A couple things: This looks good in concept. This will have to apply to HEAD cleanly, so please modify/test/repost. I'm not sure I like overloading the use of apr_proc_detach, and I'd prefer to see us come up with another function. I'm open to suggestions here. Maybe apr_proc_detach can only fork if it detects we are the process group leader? Another option would be to move the fork() out of apr_proc_detach() entirely. DONT_FORK is misleading, since we're still going to fork() in other places, just not in the parent process and with the sole purpose of killing off the original parent. Any reason why this isn't just NEW_SESSID or something akin to that? Given this patch I don't really see the purpose of NO_DETACH anymore, so maybe we could just steal that name? -aaron
Re: Running Apache in the foreground
On Thu, Jan 03, 2002 at 08:28:14AM -0800, Aaron Bannert wrote: > I see no reason why this can't be implemented in apache2, and I'll > even test and commit a patch that properly implements it. :) Sorry > I can't offer much more than that. Maybe if I get some more time > later this week I can look into it, but the more surefire way to get > it in would be to provide a patch. Here's a patch that appears to dtrt. I chose DONT_FORK as the keyword but I would happily change this or any other name to something else, just let me know. The main thing is that the patch goes in :-) Btw, the patch is against 2.0.28, I hope that is not too big of a problem; I can look into bringing it up to HEAD if desired. Thanks! lizzy:/usr/ports/www/apache2# ps -ax -o pid,ppid,pgid,command|grep httpd 297 252 252 supervise httpd 73061 297 73061 httpd -DDONT_FORK 73064 73061 73061 httpd -DDONT_FORK 73067 73061 73061 httpd -DDONT_FORK 73068 73061 73061 httpd -DDONT_FORK 73069 73061 73061 httpd -DDONT_FORK 73070 73061 73061 httpd -DDONT_FORK 73071 73061 73061 httpd -DDONT_FORK diff -ru work.dist/httpd-2_0_28/server/mpm/beos/beos.c work/httpd-2_0_28/server/mpm/beos/beos.c --- work.dist/httpd-2_0_28/server/mpm/beos/beos.c Tue Nov 6 21:29:36 2001 +++ work/httpd-2_0_28/server/mpm/beos/beos.cFri Jan 4 15:47:09 2002 @@ -946,16 +946,19 @@ static void beos_pre_config(apr_pool_t *pconf, apr_pool_t *plog, apr_pool_t *ptemp) { static int restart_num = 0; -int no_detach, debug; +int no_detach, dont_fork, debug; debug = ap_exists_config_define("DEBUG"); -if (debug) +if (debug) { no_detach = one_process = 1; +dont_fork = 0; +} else { one_process = ap_exists_config_define("ONE_PROCESS"); no_detach = ap_exists_config_define("NO_DETACH"); +dont_fork = ap_exists_config_define("DONT_FORK"); } /* sigh, want this only the second time around */ @@ -963,7 +966,7 @@ is_graceful = 0; if (!one_process && !no_detach) - apr_proc_detach(); + apr_proc_detach(dont_fork); server_pid = getpid(); } diff -ru work.dist/httpd-2_0_28/server/mpm/perchild/perchild.c work/httpd-2_0_28/server/mpm/perchild/perchild.c --- work.dist/httpd-2_0_28/server/mpm/perchild/perchild.c Tue Nov 6 21:29:36 2001 +++ work/httpd-2_0_28/server/mpm/perchild/perchild.cFri Jan 4 15:49:09 2002 @@ -1327,17 +1327,20 @@ static void perchild_pre_config(apr_pool_t *p, apr_pool_t *plog, apr_pool_t *ptemp) { static int restart_num = 0; -int no_detach, debug; +int no_detach, dont_fork, debug; int i; debug = ap_exists_config_define("DEBUG"); -if (debug) +if (debug) { no_detach = one_process = 1; +dont_fork = 0; +} else { one_process = ap_exists_config_define("ONE_PROCESS"); no_detach = ap_exists_config_define("NO_DETACH"); +dont_fork = ap_exists_config_define("DONT_FORK"); } /* sigh, want this only the second time around */ @@ -1345,7 +1348,7 @@ is_graceful = 0; if (!one_process && !no_detach) { - apr_proc_detach(); + apr_proc_detach(dont_fork); } my_pid = getpid(); diff -ru work.dist/httpd-2_0_28/server/mpm/prefork/prefork.c work/httpd-2_0_28/server/mpm/prefork/prefork.c --- work.dist/httpd-2_0_28/server/mpm/prefork/prefork.c Tue Nov 6 21:29:36 2001 +++ work/httpd-2_0_28/server/mpm/prefork/prefork.c Fri Jan 4 15:48:13 2002 @@ -1292,16 +1292,19 @@ static void prefork_pre_config(apr_pool_t *p, apr_pool_t *plog, apr_pool_t *ptemp) { static int restart_num = 0; -int no_detach, debug; +int no_detach, dont_fork, debug; debug = ap_exists_config_define("DEBUG"); -if (debug) +if (debug) { no_detach = one_process = 1; +dont_fork = 0; +} else { no_detach = ap_exists_config_define("NO_DETACH"); one_process = ap_exists_config_define("ONE_PROCESS"); +dont_fork = ap_exists_config_define("DONT_FORK"); } /* sigh, want this only the second time around */ @@ -1309,7 +1312,7 @@ is_graceful = 0; if (!one_process && !no_detach) { - apr_proc_detach(); + apr_proc_detach(dont_fork); } parent_pid = ap_my_pid = getpid(); diff -ru work.dist/httpd-2_0_28/server/mpm/threaded/threaded.c work/httpd-2_0_28/server/mpm/threaded/threaded.c --- work.dist/httpd-2_0_28/server/mpm/threaded/threaded.c Tue Nov 6 21:29:36 2001 +++ work/httpd-2_0_28/server/mpm/threaded/threaded.cFri Jan 4 15:41:19 2002 @@ -1359,7 +1359,7 @@ static void threaded_pre_config(apr_pool_t *pconf, apr_pool_t *plog, apr_pool_t *ptemp) { static int restart_num = 0; -int no_detach, debug; +int no_detach, dont_fork, debug; ap_directive_t *pdir; ap_directive_t *max_clients = NULL; @@ -1401,11 +1401,14 @@
Re: Running Apache in the foreground
On Wed, Jan 02, 2002 at 05:57:16PM -0500, Michael Handler wrote: > I'd also like to voice my support for implementing Jos' requested > functionality. NO_DETACH may have originally been intended just for > debugging purposes, but many sites are moving to universal process > managers like djb's daemontools, and it would be extremely useful > to all of us if Apache's httpd provided the necessary knob to run > under svscan & supervise out of the box. I see no reason why this can't be implemented in apache2, and I'll even test and commit a patch that properly implements it. :) Sorry I can't offer much more than that. Maybe if I get some more time later this week I can look into it, but the more surefire way to get it in would be to provide a patch. > Correct. The don't-fork-but-still-setsid mode is a specialized > method meant for process controllers only, and it should be > administrator brain damage to try and utilize it from an interactive > shell -- much like invoking a daemon with verbose debug arguments > and then complaining about the output. :) I think putting a note > in the documentation to this effect should be sufficient. Also note > that invoking this mode from shells without job control (Solaris > /bin/sh) works fine, as they don't try and create unique process > groups for each invoked job, AFAICT. I would just expect the -DFOREGROUND patch to check if httpd is the process groupleader and error out instead of calling setsid() and continuing. > I submitted a patch regarding this issue for 1.3.22 earlier today, > in which I also noted 2.0's issue with setsid(2) regarding this. > (Sorry for the bad line-wrap in the PR.) > > http://bugs.apache.org/index.cgi/full/9341 Sorry, I can't comment on 1.3, that's not my forté. Perhaps one of the ol' timers on here have something to say about it? ;) -aaron
Re: Running Apache in the foreground
[ resending because i sent from the wrong From: header last time. here's to hoping that this doesn't show up twice. apologies in advance if it does... ] I'd also like to voice my support for implementing Jos' requested functionality. NO_DETACH may have originally been intended just for debugging purposes, but many sites are moving to universal process managers like djb's daemontools, and it would be extremely useful to all of us if Apache's httpd provided the necessary knob to run under svscan & supervise out of the box. (A Google search for "apache daemontools patch" reveals patches for this functionality dating back to at least 1.3.12, which should give you an idea of how long people have been re-implementing this for each version. :)) Jos Backus wrote: > 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: Aaron Bannert responded: > 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. Correct. The don't-fork-but-still-setsid mode is a specialized method meant for process controllers only, and it should be administrator brain damage to try and utilize it from an interactive shell -- much like invoking a daemon with verbose debug arguments and then complaining about the output. :) I think putting a note in the documentation to this effect should be sufficient. Also note that invoking this mode from shells without job control (Solaris /bin/sh) works fine, as they don't try and create unique process groups for each invoked job, AFAICT. I submitted a patch regarding this issue for 1.3.22 earlier today, in which I also noted 2.0's issue with setsid(2) regarding this. (Sorry for the bad line-wrap in the PR.) http://bugs.apache.org/index.cgi/full/9341 Thanks for your consideration! --michael -- [EMAIL PROTECTED] (michael handler) washington, dc
Re: Running Apache in the foreground
I'd also like to voice my support for implementing Jos' requested functionality. NO_DETACH may have originally been intended just for debugging purposes, but many sites are moving to universal process managers like djb's daemontools, and it would be extremely useful to all of us if Apache's httpd provided the necessary knob to run under svscan & supervise out of the box. (A Google search for "apache daemontools patch" reveals patches for this functionality dating back to at least 1.3.12, which should give you an idea of how long people have been re-implementing this for each version. :)) Jos Backus wrote: > 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: Aaron Bannert responded: > 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. Correct. The don't-fork-but-still-setsid mode is a specialized method meant for process controllers only, and it should be administrator brain damage to try and utilize it from an interactive shell -- much like invoking a daemon with verbose debug arguments and then complaining about the output. :) I think putting a note in the documentation to this effect should be sufficient. Also note that invoking this mode from shells without job control (Solaris /bin/sh) works fine, as they don't try and create unique process groups for each invoked job, AFAICT. I submitted a patch regarding this issue for 1.3.22 earlier today, in which I also noted 2.0's issue with setsid(2) regarding this. (Sorry for the bad line-wrap in the PR.) http://bugs.apache.org/index.cgi/full/9341 Thanks for your consideration! --michael -- [EMAIL PROTECTED] (michael handler) washington, dc
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: 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: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
Re: Running Apache in the foreground
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. 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. Therefore the only way to ensure that the calling process is NOT the process group leader is to call fork() before calling setsid(). -aaron
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
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). [snip] > 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 > 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.) [snip] > > 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. -aaron
Re: Running Apache in the foreground
From: "Justin Erenkrantz" <[EMAIL PROTECTED]> Sent: Friday, December 28, 2001 3:31 AM > 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? True process groups weren't introduced until Win2K. That said, the Service Manager seems to be able to knock out the entire service, including children, so we should be able to do so, as well.
Re: Running Apache in the foreground
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
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;
Re: Running Apache in the foreground
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). 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''. 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? Do you have a better mechanism in mind? 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
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;