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.su
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 H
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
>
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 t
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
_/ _/ _/
_/ _/_/_/
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
>
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
>
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 pa
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 determ
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
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
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 th
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
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
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 als
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 ad
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
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
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
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), so
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
On Fri, Jan 04, 2002 at 09:13:51PM -0801, Jos Backus wrote:
> Fyi, as an aside, when building from CVS I am seeing
>
> ./config.status: 765: Syntax error: "done" unexpected (expecting ")")
>
> The script:
>
> #
> # CONFIG_COMMANDS section.
> #
> for ac_file in : $CONFIG_
Fyi, as an aside, when building from CVS I am seeing
./config.status: 765: Syntax error: "done" unexpected (expecting ")")
The script:
#
# CONFIG_COMMANDS section.
#
for ac_file in : $CONFIG_COMMANDS; do test "x$ac_file" = x: && continue
ac_dest=`echo "$ac_file" |
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 tha
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 i
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 daem
[ 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
debug
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
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
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 Ba
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 tha
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
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 proc
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
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
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
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.
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
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 cre
[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
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
>
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
42 matches
Mail list logo
