Re: daemontools/foreground support in 1.3.*
On Thu, Feb 28, 2002 at 01:29:35AM -0800, Justin Erenkrantz wrote:
http://www.apache.org/dist/httpd/contrib/patches/1.3/daemontools.patch
This should give you an official place to download it. I
have also added a note in 1.3's STATUS.
Btw, the above patch no longer applies cleanly to 1.3.24. Can you please
update the patch with the one attached to this message?
Thanks!
--
Jos Backus _/ _/_/_/Santa Clara, CA
_/ _/ _/
_/ _/_/_/
_/ _/ _/_/
[EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
--- src/main/http_main.cSat Mar 23 00:26:38 2002
+++ src/main/http_main.cSat Mar 23 00:30:17 2002
@@ -341,6 +341,8 @@
static int one_process = 0;
+static int do_detach = 1;
+
/* set if timeouts are to be handled by the children and not by the parent.
* i.e. child_timeouts = !standalone || one_process.
*/
@@ -1349,7 +1351,7 @@
#ifdef WIN32
fprintf(stderr, Usage: %s [-D name] [-d directory] [-f file] [-n service]\n,
bin);
fprintf(stderr,%s [-C \directive\] [-c \directive\] [-k signal]\n,
pad);
-fprintf(stderr,%s [-v] [-V] [-h] [-l] [-L] [-S] [-t] [-T]\n, pad);
+fprintf(stderr,%s [-v] [-V] [-h] [-l] [-L] [-S] [-t] [-T] [-F]\n, pad);
#else /* !WIN32 */
#ifdef SHARED_CORE
fprintf(stderr, Usage: %s [-R directory] [-D name] [-d directory] [-f file]\n,
bin);
@@ -1357,7 +1359,7 @@
fprintf(stderr, Usage: %s [-D name] [-d directory] [-f file]\n, bin);
#endif
fprintf(stderr,%s [-C \directive\] [-c \directive\]\n, pad);
-fprintf(stderr,%s [-v] [-V] [-h] [-l] [-L] [-S] [-t] [-T]\n, pad);
+fprintf(stderr,%s [-v] [-V] [-h] [-l] [-L] [-S] [-t] [-T] [-F]\n, pad);
fprintf(stderr, Options:\n);
#ifdef SHARED_CORE
fprintf(stderr, -R directory : specify an alternate location for shared
object files\n);
@@ -1380,6 +1382,7 @@
#endif
fprintf(stderr, -t : run syntax check for config files (with
docroot check)\n);
fprintf(stderr, -T : run syntax check for config files (without
docroot check)\n);
+fprintf(stderr, -F : run main process in foreground, for process
+supervisors\n);
#ifdef WIN32
fprintf(stderr, -n name : name the Apache service for -k options
below;\n);
fprintf(stderr, -k stop|shutdown : tell running Apache to shutdown\n);
@@ -3370,14 +3373,16 @@
!defined(BONE)
/* Don't detach for MPE because child processes can't survive the death of
the parent. */
-if ((x = fork()) 0)
- exit(0);
-else if (x == -1) {
- perror(fork);
- fprintf(stderr, %s: unable to fork new process\n, ap_server_argv0);
- exit(1);
+if (do_detach) {
+if ((x = fork()) 0)
+exit(0);
+else if (x == -1) {
+perror(fork);
+ fprintf(stderr, %s: unable to fork new process\n, ap_server_argv0);
+ exit(1);
+}
+RAISE_SIGSTOP(DETACH);
}
-RAISE_SIGSTOP(DETACH);
#endif
#ifndef NO_SETSID
if ((pgrp = setsid()) == -1) {
@@ -5308,7 +5313,7 @@
ap_setup_prelinked_modules();
while ((c = getopt(argc, argv,
- D:C:c:xXd:f:vVlLR:StTh
+ D:C:c:xXd:Ff:vVlLR:StTh
#ifdef DEBUG_SIGSTOP
Z:
#endif
@@ -5330,6 +5335,9 @@
case 'd':
ap_cpystrn(ap_server_root, optarg, sizeof(ap_server_root));
break;
+ case 'F':
+ do_detach = 0;
+ break;
case 'f':
ap_cpystrn(ap_server_confname, optarg, sizeof(ap_server_confname));
break;
@@ -7211,9 +7219,9 @@
reparsed = 1;
}
-while ((c = getopt(argc, argv, D:C:c:Xd:f:vVlLz:Z:wiuStThk:n:W:)) != -1) {
+while ((c = getopt(argc, argv, D:C:c:Xd:fF:vVlLz:Z:wiuStThk:n:W:)) != -1) {
#else /* !WIN32 */
-while ((c = getopt(argc, argv, D:C:c:Xd:f:vVlLesStTh)) != -1) {
+while ((c = getopt(argc, argv, D:C:c:Xd:fF:vVlLesStTh)) != -1) {
#endif
char **new;
switch (c) {
@@ -7335,6 +7343,9 @@
ap_server_root[strlen(ap_server_root) - 1] == '/')
ap_server_root[strlen(ap_server_root) - 1] = '\0';
break;
+ case 'F':
+ do_detach = 0;
+ break;
case 'f':
ap_cpystrn(ap_server_confname,
ap_os_canonical_filename(pcommands, optarg),
@@ -7729,13 +7740,14 @@
* but only handle the -L option
*/
llp_dir = SHARED_CORE_DIR;
-while ((c = getopt(argc, argv, D:C:c:Xd:f:vVlLR:SZ:tTh)) != -1) {
+while ((c = getopt(argc, argv, D:C:c:Xd:Ff:vVlLR:SZ:tTh)) != -1) {
switch (c) {
case 'D':
case 'C':
case 'c':
case 'X':
case 'd':
+ case 'F':
case 'f':
Re: daemontools/foreground support in 1.3.*
On Tue, Feb 26, 2002 at 07:49:34PM -0800, Jos Backus wrote: On Tue, Feb 26, 2002 at 07:21:16AM -0800, Aaron Bannert wrote: On Mon, Feb 25, 2002 at 05:26:44PM -0500, Michael Handler wrote: hi, guys. i've posted this patch for foreground/supervise support FWIW, by just eyeballing this patch I can say it looks good. It is exactly how I would have done it. Fwiw, same here. It is very unintrusive, less so even than the patch that went into 2.0. Please consider including it. Fyi, I plan on submitting a patch to the FreeBSD port maintainer to include this patch automatically in 1.3.24 when it is released. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: daemontools/foreground support in 1.3.*
Sorry for the lack of quick response, I had to go home for a family funeral. Justin Erenkrantz [EMAIL PROTECTED] writes: -0. I personally believe that this shouldn't be backported. If you want this, you should use 2.0. Others will disagree vehemently though, and you may indeed garner enough +1s to get it in. IMHO, 1.3 should be in bug-fix mode only. No new features - as witnessed by our addition of AcceptMutex which screwed up 1.3.23 on Solaris. If you need this functionality, why not use 2.0 and help us get 2.0 to be GA? I completely understand the desire to not to introduce substantial changes into 1.3.* at this point, as well as encouraging people to test the stability and correctness of 2.0. However: * 2.0 is not ready for production deployment, and arguably won't be for some time. Thus, we need to keep running 1.3 in production until that time, and will need minor support to keep it running optimally in our environments. I'm perfectly happy to deploy 2.0 in testing environments, and the daemontools support will make that abundantly easier, but I still need 1.3.* right now, and that means patching every release each time to run under daemontools. I first wrote this patch for 1.3.14 when I was doing the first software deploy at my current employer (August 2000). I thought about contributing it back to Apache then, but decided against it, since I was (mistakenly) informed that 2.0 already had this functionality, and I thought that 2.0 would be production quality soon. * This is a very minor change, on the order of 20 lines of code. I've personally been running this patch in production since 1.3.14, and I've found patches on the Internet that date back to 1.3.11 and earlier, so there is clearly historical demand for this functionality, as well as reason to believe that the current patch is functional and correct. Traffic on the daemontools mailing list and the number of people who have downloaded the patches from my web server since I have announced them here and elsewhere shows that there is clearly substantial interest in daemontools and running all available server processes under supervise and svscan, including Apache's httpd. Yes, nothing stops me from distributing this functionality as a patch in the contrib tarball for each release, or from my web page, but that also means that binary packages or OS distributions most likely won't have this trivial but extremely useful bit of functionality included, and that means each binary maintainer either has to be lobbied to include this, or each sysadmin has to compile their own binaries, which strikes me as clear inefficiency that could easily be avoided. This is a tiny change, and the functionality already exists in 2.0. Lots of sysadmins are going to be stuck with 1.3.* for a while from now, and this is a clear benefit to those of us who utilize daemontools, without causing any harm to anyone. I've had to write patches for several server applications to get them running cleanly under daemontools, as have many other sysadmins, but thanks to the work of Jos Backus and others, they've been integrated back into the mainline of the distribution (rsync and SAMBA come to mind as two recent examples). The 1.3.* Apache tree is the final outlier in this regard in my common set of UNIX server applications, and it would save many people work in the future to have this integrated into the next 1.3.* release. Am I reaching anyone here, or should I just be quiet? -- [EMAIL PROTECTED] (michael handler) washington, dc
Re: daemontools/foreground support in 1.3.*
On Thu, Feb 28, 2002 at 04:00:34AM -0500, Michael Handler wrote: I completely understand the desire to not to introduce substantial changes into 13* at this point, as well as encouraging people to test the stability and correctness of 20 However: I have added it to our contrib section for now: http://wwwapacheorg/dist/httpd/contrib/patches/13/daemontoolspatch This should give you an official place to download it I have also added a note in 13's STATUS And, BTW, I would appreciate it if people would stop spreading FUD like 20 arguably won't be [ready] for some time It's in production usage right now *You* may not judge it production quality - most of us do The only thing stopping a GA is some API changes (Cliff!) and small bugfixes (fast_redirect, worker robustness) We also need to wait to give the 3rd-party providers one last chance to get their modules working (php) -- justin
RE: daemontools/foreground support in 1.3.*
From: Justin Erenkrantz [mailto:[EMAIL PROTECTED]] Sent: 28 February 2002 10:30 To: Michael Handler Cc: [EMAIL PROTECTED] Subject: Re: daemontools/foreground support in 1.3.* On Thu, Feb 28, 2002 at 04:00:34AM -0500, Michael Handler wrote: I completely understand the desire to not to introduce substantial changes into 1.3.* at this point, as well as encouraging people to test the stability and correctness of 2.0. However: I have added it to our contrib section for now: http://www.apache.org/dist/httpd/contrib/patches/1.3/daemontools.patch This should give you an official place to download it. I have also added a note in 1.3's STATUS. And, BTW, I would appreciate it if people would stop spreading FUD like 2.0 arguably won't be [ready] for some time. It's in production usage right now. *You* may not judge it production quality - most of us do. The only thing stopping a GA is some API changes (Cliff!) *caugh* and *caugh* me *caugh* I need to change the pools api one more time. The allocators can be abstracted out and that best be done before GA IMO. To be changed:apr_pool_create_ex To be introduced: apr_allocator_create, apr_allocator_destroy, apr_allocator_alloc, apr_allocator_free, ... and small bugfixes (fast_redirect, worker robustness). We also need to wait to give the 3rd-party providers one last chance to get their modules working (php). -- justin Sander
Re: daemontools/foreground support in 1.3.*
On Thu, 2002-02-28 at 04:00, Michael Handler wrote: This is a tiny change, and the functionality already exists in 20 Lots of sysadmins are going to be stuck with 13* for a while from now, and this is a clear benefit to those of us who utilize daemontools, without causing any harm to anyone Am I reaching anyone here, or should I just be quiet? This is a useful patch So useful to me that I just wrote an equivalent one yesterday This is one time that I really should have read the list archives before I started hacking http://marctheaimsgroupcom/?l=apache-new-httpdm=101484615220466w=2 My aim was only for Cygwin, but should work on most unix-like platforms with the removal of some ifdefs The implementation in daemontoolspatch appears to be a bit cleaner than the one I submitted Also, the patch that was put in place at http://wwwapacheorg/dist/httpd/contrib/patches/13/daemontoolspatch is not readable Could someone do a chmod a+r on it? Mike
Re: daemontools/foreground support in 1.3.*
| I am of the mind that it should not be added, but I won't stop anyone | if they garner 3 +1s from actual testing and feedback. Anyone willing to step up with any +1s? It's an easy compile and test, folks; just remember to run it under a shell without job control. Justin Erenkrantz [EMAIL PROTECTED] writes: I have added it to our contrib section for now: http://www.apache.org/dist/httpd/contrib/patches/1.3/daemontools.patch Are you, or someone else, willing to commit to updating this location with the new version of the patch I'll generate for each successive version of 1.3? If not, I'd rather you removed this patch from this location, as I'd rather maintain it on my web server where I can update it without having to wait on the free time of anyone else. I have also added a note in 1.3's STATUS. Thank you. And, BTW, I would appreciate it if people would stop spreading FUD like 2.0 arguably won't be [ready] for some time. It's in production usage right now. *You* may not judge it production quality - most of us do. You're entitled to your opinion, and me to mine. The simple truth from my perspective is that on March 10, 2002, it will have been two years since the first release of Apache 2.0 alpha. That's an awfully long development period, and unabashed ground-up rewrites of giant software projects that ALSO introduce substantial new features are, to me and most of my sysadmin friends that I have discussed this with, something that makes us nervous. I'm going to have to do exhaustive testing of the various functionality of 2.0 before I'm comfortable releasing it into production in my environment, and I'm going to do so slowly, cautiously, and while closely watching the experiences of others. I'm not directly critiquing the development process for 2.0; I wasn't involved, and I have no claim that I could have done it better. I AM saying that I think you are underestimating the initial resistance that the 2.0 final release is going to encounter, and how long the later/final releases of 1.3.* are going to hang around. This is not an argument for backporting a substantial portion of 2.0's new functionality, or making any other substantial changes, but merely for applying a twenty line patch that has been tested for the last eleven versions and would demonstratably simplify the lives of sysadmins who gratefully run your package at many, many sites. What high-volume sites is 2.0 running on other than daedalus and icarus? -- [EMAIL PROTECTED] (michael handler) washington, dc
Re: daemontools/foreground support in 1.3.*
On Fri, Mar 01, 2002 at 01:03:33AM -0500, Michael Handler wrote: | I am of the mind that it should not be added, but I won't stop anyone | if they garner 3 +1s from actual testing and feedback. Does my +1 count? -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: daemontools/foreground support in 1.3.*
On Tue, 26 Feb 2002, Lars Eilebrecht wrote: According to Justin Erenkrantz: -0. I personally believe that this shouldn't be backported. If you want this, you should use 2.0. I tend to agree. -0 from me as well. There will always be a nice feature which could be backported, but IMHO we should avoid it unless there is a _very_ good reason. A good reason is: _I_ need it. Or in other words - if there are volunteers/folks who want a specific feature in 1.3 -and- are willing to work on it and maintain it; I'd be loath to get in their way. Standing in the way of honest people who have to get their days work done (and who for some arcane reason are tied to 1.3) fo the sake of 'forcing' the world to 2.0 is not the right thing. Apache is tied into too many operations systems for those sort of upgrade tactics to be effective. Gradually 2.0 will be picked up by peple when 2.0 is ready for the world at large and people are ready for 2.0. For those in that ops space - 2.0 has got enough qualities to make it there on its own accord (flexible child/process management, filters, binary compatibility, can I make you drule even more ?) But making things painfull by -and- allow the closing down of 1.3 forcefully -and- 2.0 being a moving target is not the right thing. A '-0' or '-1' should be given for more technical reasons in my opinion. And for those simply not interested in the 1.3 branch - then do not vote or give it a '0'. FreeBSD's 'release' and 'current' and the MFC merging has always seemed like the right thing to me. Dw
Re: daemontools/foreground support in 1.3.*
At 05:05 AM 2/26/2002, [EMAIL PROTECTED] wrote: On Tue, 26 Feb 2002, Lars Eilebrecht wrote: According to Justin Erenkrantz: -0. I personally believe that this shouldn't be backported. If you want this, you should use 2.0. I tend to agree. -0 from me as well. There will always be a nice feature which could be backported, but IMHO we should avoid it unless there is a _very_ good reason. Standing in the way of honest people who have to get their days work done (and who for some arcane reason are tied to 1.3) fo the sake of 'forcing' the world to 2.0 is not the right thing. Apache is tied into too many operations systems for those sort of upgrade tactics to be effective. But making things painfull by -and- allow the closing down of 1.3 forcefully -and- 2.0 being a moving target is not the right thing. 100% Agreed. However, I also agree we do not want to destabilize the 2.0 program [look at what a moving target the MPM architectures are on 2.0 - we don't want 1.3 to suffer the same.] If the author has gone to the effort - and this is only used for installs using one of several management tools - this is _the_ perfect use of /dist/httpd/contrib/patches. We were extremely anxious about tacking in the HTTP/1.1 proxy changes. Took us a year to accept them as 'ready', a year of some hard work by the proxy-dev list. For some 5 revs or so, the patch was available. It wasn't widely adopted, but folks did grab it, and contribute their feedback. This helped assure that rolling it into apache-1.3 cvs wouldn't harm the server. Can we please accept this backport and make it available in either patches/ or contrib/, to reflect the effort our contributor has already gone to? And if over a few versions, some folks get testing, and report the change is stable across platforms, then we would roll this improvement in. If we never released another 1.3, it would still be available for those who need it. A '-0' or '-1' should be given for more technical reasons in my opinion. And for those simply not interested in the 1.3 branch - then do not vote or give it a '0'. Bravo. It's not unreasonable to reject code to 1.3 that is unsupported in 2.0 [with a port or patch] but if someone is willing to hack the 2.0 as well as 1.3 code, then it's silly to stand in their way over 'this branch is dead code.' Bill
Re: daemontools/foreground support in 1.3.*
I agree with Dirk-Willem. I'm much less sympathetic to the it's time to move on arguments these days. I think we have given 2.0 plenty of headroom. 1.3 won't die out for a very long time and we can be nice about that. Of course 2.0 should get the vast majority of our calories. 1.3 is very stable software. Changes to it need to climb over a very high quality barrier. That requires a depth of skilled labor to do the review. The labor, with commit rights, to work on 1.3 is pretty thin on the ground. Daemontools is _very_ good stuff. I recomend looking into it. Very elegant design. Like it's siblings qmail and dbjdns it requires a moment to get into it's mindset. The patch http://makeashorterlink.com/?R4E33267 is extremely straight forward. My only reservation is that main.c in 1.3 is a mess and that has a tendency to bite you. - ben [EMAIL PROTECTED] wrote: On Tue, 26 Feb 2002, Lars Eilebrecht wrote: According to Justin Erenkrantz: -0. I personally believe that this shouldn't be backported. If you want this, you should use 2.0. I tend to agree. -0 from me as well. There will always be a nice feature which could be backported, but IMHO we should avoid it unless there is a _very_ good reason. A good reason is: _I_ need it. Or in other words - if there are volunteers/folks who want a specific feature in 1.3 -and- are willing to work on it and maintain it; I'd be loath to get in their way. Standing in the way of honest people who have to get their days work done (and who for some arcane reason are tied to 1.3) fo the sake of 'forcing' the world to 2.0 is not the right thing. Apache is tied into too many operations systems for those sort of upgrade tactics to be effective. Gradually 2.0 will be picked up by peple when 2.0 is ready for the world at large and people are ready for 2.0. For those in that ops space - 2.0 has got enough qualities to make it there on its own accord (flexible child/process management, filters, binary compatibility, can I make you drule even more ?) But making things painfull by -and- allow the closing down of 1.3 forcefully -and- 2.0 being a moving target is not the right thing. A '-0' or '-1' should be given for more technical reasons in my opinion. And for those simply not interested in the 1.3 branch - then do not vote or give it a '0'. FreeBSD's 'release' and 'current' and the MFC merging has always seemed like the right thing to me. Dw -- http://www.cozy.org:83/bhyde.html
Re: daemontools/foreground support in 1.3.*
On Mon, Feb 25, 2002 at 05:26:44PM -0500, Michael Handler wrote: hi, guys. i've posted this patch for foreground/supervise support FWIW, by just eyeballing this patch I can say it looks good. It is exactly how I would have done it. -aaron
Re: daemontools/foreground support in 1.3.*
On Tue, Feb 26, 2002 at 07:21:16AM -0800, Aaron Bannert wrote: On Mon, Feb 25, 2002 at 05:26:44PM -0500, Michael Handler wrote: hi, guys. i've posted this patch for foreground/supervise support FWIW, by just eyeballing this patch I can say it looks good. It is exactly how I would have done it. Fwiw, same here. It is very unintrusive, less so even than the patch that went into 2.0. Please consider including it. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
daemontools/foreground support in 1.3.*
hi, guys. i've posted this patch for foreground/supervise support
in the 1.3.* tree four times since january fifth (when the thread
for support for this in 2.0 started), and i haven't heard word one
back from anyone with commit access... i'd really like to see this
(very simple) feature backported from 2.0 into the 1.3.* tree for
consistency's sake, and i'd be ecstatic if i could get it in under
the wire for the 1.3.24 release. can i get some feedback on my
patch? is there something i'm missing or doing wrong that would
preclude this from being applied?
thanks for all of your time and hard work. --michael
patch attached, also available at:
http://www.sub-rosa.com/handler/pub/apache-1.3.23-foreground-patch
--
[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,
ap_os_canonical_filename(pcommands, optarg),
@@ -7690,13 +7701,14 @@
* but only handle the -L option
*/
llp_dir = SHARED_CORE_DIR;
-while ((c = getopt(argc, argv, D:C:c:Xd:f:vVlLR:SZ:tTh)) != -1) {
+while ((c = getopt(argc, argv, D:C:c:Xd:Ff:vVlLR:SZ:tTh)) != -1) {
Re: daemontools/foreground support in 1.3.*
On Mon, Feb 25, 2002 at 05:26:44PM -0500, Michael Handler wrote: hi, guys. i've posted this patch for foreground/supervise support in the 1.3.* tree four times since january fifth (when the thread for support for this in 2.0 started), and i haven't heard word one back from anyone with commit access... i'd really like to see this (very simple) feature backported from 2.0 into the 1.3.* tree for consistency's sake, and i'd be ecstatic if i could get it in under the wire for the 1.3.24 release. can i get some feedback on my patch? is there something i'm missing or doing wrong that would preclude this from being applied? -0. I personally believe that this shouldn't be backported. If you want this, you should use 2.0. Others will disagree vehemently though, and you may indeed garner enough +1s to get it in. IMHO, 1.3 should be in bug-fix mode only. No new features - as witnessed by our addition of AcceptMutex which screwed up 1.3.23 on Solaris. If you need this functionality, why not use 2.0 and help us get 2.0 to be GA? My $.02 - feel free to ignore me. -- justin
Re: daemontools/foreground support in 1.3.*
Justin Erenkrantz [EMAIL PROTECTED] writes: IMHO, 1.3 should be in bug-fix mode only. No new features - as witnessed by our addition of AcceptMutex which screwed up 1.3.23 on Solaris. If you need this functionality, why not use 2.0 and help us get 2.0 to be GA? My SNAFU with no -lpthread notwithstanding, I can assure you that at least *I* have had more time to work on 2.0 thanks to Jim's AcceptMutex work in 1.3 :) That unresolved Solaris problem with fcntl and SiteMinder? The workaround is to use AcceptMutex foo. That problem with AcceptMutex pthread where once we fixed the code to close a timing window we aren't always able to kill idle children? The work-around is to use AcceptMutex foo. -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
