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 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
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_cpystrn(ap_server_confname,
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
neither param - 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) {
is_graceful = 0;
-
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, 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 neither param - 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
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
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 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;
if (attr-detached) {
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 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: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 2001 23:16:24
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 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 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 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 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 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 @@
debug =
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 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
[ 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
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
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 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.350r2=1.351f=h -- 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;
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
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:
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
On Fri, Dec 28, 2001 at 10:09:12AM -0800, Aaron Bannert wrote:
AIUI the reason we call fork() before calling setsid() is to guarantee
that we are _not_ the process group leader. Calling setsid() will fail
if the calling process has the same PID as process group ID.
I haven't tried this (yet) with Apache but a similar approach with {n,s}mbd
seems to work properly. Here is what the code in
samba-3.0-alpha12/source/lib/util.c looks like. I don't see the setsid()
failing with dont_fork == 1.
/
Become a daemon, discarding the controlling terminal.
/
void become_daemon(BOOL dont_fork)
{
if (!dont_fork sys_fork()) {
_exit(0);
}
/* detach from the terminal */
#ifdef HAVE_SETSID
if (setsid() == -1)
DEBUG(0, (setsid() failed: %s\n, strerror(errno)));
#elif defined(TIOCNOTTY)
{
int i = sys_open(/dev/tty, O_RDWR, 0);
if (i != -1) {
ioctl(i, (int) TIOCNOTTY, (char *)0);
close(i);
}
}
#endif /* HAVE_SETSID */
/* Close fd's 0,1,2. Needed if started by rsh */
close_low_fds();
}
It seems like I'm missing something here, and I guess I don't quite
understand the problem that you're describing. Is this only a problem
with NO_DETACH? Please realize that NO_DETACH is a debugging tool.
I know that, and I am trying to find a way to implement a -DFOREGROUND flag as
a variation on the NO_DETACH flag, which means that the parent httpd stays
around instead of forking and exiting.
I may be wrong here, but I don't think it was the intention of NO_DETACH
to support auto-daemonizing tools. Apache does that already (although
perhaps not the way we thought it did).
I am coming into this from a sysadmin point of view. I want to be able to use
a process monitor (AIX's SRC/daemontools/whatever) because it avoids code
dauplication and pid file races, handles automatic restarts and provides me
with a single platform-indendent management interface.
In order for httpd to support this mode of operation it should not fork (and
decouple itself from its parent) but still run in its own process group, so
that this pgrp only contains it and its children. A workaround would be to use
the pgrphack program that comes with daemontools, which looks like this:
#include unistd.h
#include strerr.h
#include pathexec.h
#define FATAL pgrphack: fatal:
int main(int argc,const char * const *argv,const char * const *envp)
{
if (!argv[1]) strerr_die1x(100,pgrphack: usage: pgrphack child);
setsid(); /* shouldn't fail; if it does, too bad */
pathexec_run(argv[1],argv + 1,envp);
strerr_die4sys(111,pgrphack: fatal: ,unable to run ,argv[1],: );
}
But I haven't tested this and I'd much rather see this functionality in httpd
(it's a hack, after all).
So the use of the second 0 strikes me as suspicious and likely wrong.
OK, I overreacted, sorry. But the macro names should match.
Just to add to what Justin said, setpgid(0,0) effectively means create a
new process group with the calling process as the process group leader. If
we were to call setsid() (which seems like we should be doing) we'd ensure
that we are fully detaching from the controlling terminal. Of course, this
*must* happen after a fork().
Could it be that the process supervisor does something special to make this
work? That could explain why the Samba daemons seem to run properly under the
process monitor with my patch.
The FreeBSD Apache port currently uses a patch located at
http://fallin.lv/distfiles/apache-2.0.28_1.diff; maybe you can verify
this and commit this fix so the patch can go away. Hye-Shik Chang told me
he entered a Apache problem report for this issue.
Can someone perhaps better describe what's happening in this patch, or
provide a patch against configure.in directly? I was thinking that we might
want to check for _POSIX_JOB_CONTROL or do some other autoconf magic to make
sure that we have setsid() and that it does what we want. (Not sure if
_POSIX_JOB_CONTROL is supposed to be defined for setsid() the way it is for
setpgid() though.)
I thought it was simply a matter of changing the macro name or adding an extra
definition. Maybe the patch author can comment?
--
Jos Backus _/ _/_/_/Santa Clara, CA
_/ _/ _/
_/ _/_/_/
_/ _/ _/_/
[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 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: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: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 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;
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;
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
