On Mon, Apr 17, 2023 at 10:16 AM jean-frederic clere wrote:
>
> On 4/17/23 01:00, Eric Covener wrote:
> > On Fri, Apr 14, 2023 at 11:49 AM jean-frederic clere
> > wrote:
> >>
> >> Hi,
> >>
> >> I am try to gracefully stop a child process instead using ap_assert(0),
> >> is there a "clean way"
On 4/17/23 01:00, Eric Covener wrote:
On Fri, Apr 14, 2023 at 11:49 AM jean-frederic clere wrote:
Hi,
I am try to gracefully stop a child process instead using ap_assert(0),
is there a "clean way" to do that?
I added something like this to our distribution in IBM to address a
hairy problem
On Fri, Apr 14, 2023 at 11:49 AM jean-frederic clere wrote:
>
> Hi,
>
> I am try to gracefully stop a child process instead using ap_assert(0),
> is there a "clean way" to do that?
I added something like this to our distribution in IBM to address a
hairy problem with our security library.
Each
Hi,
I am try to gracefully stop a child process instead using ap_assert(0),
is there a "clean way" to do that?
--
Cheers
Jean-Frederic
Hi everyone,
A couple of days a go i noticed that apache2ctl uses the signal SIGWINCH
to send a graceful-stop. This is obviously a very bad idea. e.g. try
starting httpd -X and change your window size ;)
I am proposing to use the SIGUSR2 signal (see the diff).
The first diff is for apache2
On Mon, Aug 20, 2007 at 04:00:48PM -0700, Paul Querna wrote:
Short: We need to call ap_close_listeners() earlier or more aggressively.
Question: Where/How?
Looking at the Event MPM in both trunk and 2.2.x, the listener_thread is
where we call ap_close_listeners(). This does not seem to be
On Aug 20, 2007, at 7:00 PM, Paul Querna wrote:
Short: We need to call ap_close_listeners() earlier or more
aggressively.
Question: Where/How?
Looking at the Event MPM in both trunk and 2.2.x, the
listener_thread is
where we call ap_close_listeners(). This does not seem to be working
Short: We need to call ap_close_listeners() earlier or more aggressively.
Question: Where/How?
Looking at the Event MPM in both trunk and 2.2.x, the listener_thread is
where we call ap_close_listeners(). This does not seem to be working
quickly enough, per PR 43081:
Hi,
I am new to this group, so
please be gentle :)
Recently, I installed apache
2.2.3 on a Crux 2.1 (Linux Kernel 2.6.11.7). Now, every time I do an apachectl
graceful or apachectl graceful-stop I get [error] (9)Bad file descriptor:
apr_socket_accept: (client socket) in the apache
Now that the ap_close_listeners() code is committed, implementing a
graceful stop is relatively trivial, I already have it working here for
me. However there are some complicated nits which I thought I'd solicit
feedback on.
One of the main benefits of a graceful stop is to allow for upgrading
On Thu, Aug 25, 2005 at 11:01:14AM +0100, Colm MacCarthaigh wrote:
Now that the ap_close_listeners() code is committed, implementing a
graceful stop is relatively trivial, I already have it working here for
me. However there are some complicated nits which I thought I'd solicit
feedback
On Thu, Aug 25, 2005 at 11:17:29AM +0100, Joe Orton wrote:
apachectl graceful-stop
apachectl start
and have it work as the admin would expect, but this leads to some
complications. Files like the ScriptSock, ScoreBoardFile,
SSLSessionCache, LockFile, LDAPSharedCacheFile and so
On Aug 25, 2005, at 6:01 AM, Colm MacCarthaigh wrote:
Now that the ap_close_listeners() code is committed, implementing a
graceful stop is relatively trivial, I already have it working here
for
me. However there are some complicated nits which I thought I'd
solicit
feedback on.
One
Quoting Colm MacCarthaigh [EMAIL PROTECTED] (2005-08-25 11:01:14 BST):
Has anyone got any comments on any other approaches? or on the
suitability of adding a small ammount of expansion to the state-related
directives above?
I've always felt it was a shame that you could do -DFOO but not
Hello,
CMWhy does graceful restart exist? Wouldn't it be better to have
CMa graceful stop, and then just start a new instance?
CM...
CM * httpd could be upgraded without dropping clients
I don't see how this would work--a graceful stop followed by a start would
mean clients would drop
On Tue, Jan 20, 2004 at 10:17:07AM -0800, Andrew Ho wrote:
I don't see how this would work--a graceful stop followed by a start would
mean clients would drop in between the window when you signal the graceful
stop (and Apache therefore stops accepting new requests) and when the new
instance
This has probably been discussed here before, and if it has I'd
like to know the reasons why it's a bad idea. Anyway, I've been
working on a graceful stop mechanism for httpd, which is
reasonably trivial to work in - the problem is that there are
no portable signal numbers left (or am I wrong
17 matches
Mail list logo
