On 9/21/21 9:56 AM, Ruediger Pluem wrote:
> I am just investigating a case where a httpd 2.4.49 gets stuck and as part of
> the investigation
> I am asking myself if we should count processes that die because of
> MaxRequestsPerChild still count
> to active_daemons?
> Because if we do like tod
Build Update for apache/httpd
-
Build: #1955
Status: Fixed
Duration: 9 mins and 52 secs
Commit: dda1303 (trunk)
Author: Yann Ylavic
Message: mod_optional_hook_import: debug message at APLOG_DEBUG level.
git-svn-id: https://svn.apache.org/repos/asf/httpd/http
Build Update for apache/httpd
-
Build: #1954
Status: Broken
Duration: 11 mins and 46 secs
Commit: a117a32 (trunk)
Author: Ruediger Pluem
Message: * Follow up to r1893497: Make use of ap_pre_connection in mpm_motorz
and mpm_simple_io
git-svn-id: https://svn.ap
Does the attached patch solve your issue?
Regards
Rüdiger
On 9/20/21 8:01 PM, Evgeny Kotkov wrote:
> Hi,
>
> I think that I have stumbled across a significant regression in httpd 2.4.49
> where mod_dav has been changed in a way that makes it ignore the errors
> returned by a versioning provider
On 9/21/21 2:10 PM, Yann Ylavic wrote:
> On Tue, Sep 21, 2021 at 12:25 PM Ruediger Pluem wrote:
>>
>> On 9/20/21 1:31 PM, Yann Ylavic wrote:
>>>
>>> For CONN_STATE_WRITE_COMPLETION + CONN_SENSE_WANT_READ we indeed reach
>>> here and will POLLIN, then once readable we come back with
>>> CONN_STA
On 9/21/21 2:26 PM, Yann Ylavic wrote:
> On Tue, Sep 21, 2021 at 1:38 PM Ruediger Pluem wrote:
>>
>> How about the below?
>
> +1, we possibly need to change all the calls to
> ap_run_pre_connection() by ap_pre_connection() then, not only in
> mpm_event?
I am not sure if this is needed everywh
On Tue, Sep 21, 2021 at 1:38 PM Ruediger Pluem wrote:
>
> How about the below?
+1, we possibly need to change all the calls to
ap_run_pre_connection() by ap_pre_connection() then, not only in
mpm_event?
Cheers;
Yann.
On Tue, Sep 21, 2021 at 12:25 PM Ruediger Pluem wrote:
>
> On 9/20/21 1:31 PM, Yann Ylavic wrote:
> >
> > For CONN_STATE_WRITE_COMPLETION + CONN_SENSE_WANT_READ we indeed reach
> > here and will POLLIN, then once readable we come back with
> > CONN_STATE_WRITE_COMPLETION + CONN_SENSE_DEFAULT so if
On 9/21/21 12:03 PM, Yann Ylavic wrote:
> On Tue, Sep 21, 2021 at 11:52 AM ste...@eissing.org
> wrote:
>>
>>
>>
>>> Am 21.09.2021 um 11:48 schrieb Ruediger Pluem :
>>>
>>>
>>> But I think it is incomplete. I think we should do all that
>>> core_pre_connection does.
>>> We cannot call it from
On 9/20/21 1:31 PM, Yann Ylavic wrote:
> On Mon, Sep 20, 2021 at 12:43 PM ste...@eissing.org
> wrote:
>>
>>> Am 20.09.2021 um 12:27 schrieb Ruediger Pluem :
>>>
>>> On 9/20/21 11:17 AM, ste...@eissing.org wrote:
> Am 14.09.2021 um 13:43 schrieb Ruediger Pluem :
>
>> --- httpd/
On Tue, Sep 21, 2021 at 11:52 AM ste...@eissing.org wrote:
>
>
>
> > Am 21.09.2021 um 11:48 schrieb Ruediger Pluem :
> >
> > I noticed a crash in process_lingering_close
> >
> > The crash happens here:
> >
> > #0 0x7f5d4af33b28 in apr_socket_timeout_set (sock=sock@entry=0x0,
> > t=t@entry=20
> Am 21.09.2021 um 11:48 schrieb Ruediger Pluem :
>
> I noticed a crash in process_lingering_close
>
> The crash happens here:
>
> #0 0x7f5d4af33b28 in apr_socket_timeout_set (sock=sock@entry=0x0,
> t=t@entry=200) at network_io/unix/sockopt.c:86
>stat =
> #1 0x0047
I noticed a crash in process_lingering_close
The crash happens here:
#0 0x7f5d4af33b28 in apr_socket_timeout_set (sock=sock@entry=0x0,
t=t@entry=200) at network_io/unix/sockopt.c:86
stat =
#1 0x004706a4 in process_lingering_close (cs=0x7f5c88000ed0) at
event.c:1466
I am just investigating a case where a httpd 2.4.49 gets stuck and as part of
the investigation
I am asking myself if we should count processes that die because of
MaxRequestsPerChild still count
to active_daemons?
Because if we do like today we may prevent replacement processes to be started
wh
14 matches
Mail list logo
