https://bz.apache.org/bugzilla/show_bug.cgi?id=65769
--- Comment #42 from Yann Ylavic ---
(In reply to Teodor Milkov from comment #41)
> (In reply to Teodor Milkov from comment #40)
> > I've manually added the patches from
> > https://www.mail-archive.com/dev@httpd.apache.org/msg76497.html
>
> I
https://bz.apache.org/bugzilla/show_bug.cgi?id=65769
--- Comment #41 from Teodor Milkov ---
(In reply to Teodor Milkov from comment #40)
> I've manually added the patches from
> https://www.mail-archive.com/dev@httpd.apache.org/msg76497.html
I confirm, that with this patch httpd is running stabl
https://bz.apache.org/bugzilla/show_bug.cgi?id=65769
--- Comment #40 from Teodor Milkov ---
I've manually added the patches from
https://www.mail-archive.com/dev@httpd.apache.org/msg76497.html and more
specifically:
https://svn.apache.org/viewvc?view=revision&revision=1899858
https://sv
https://bz.apache.org/bugzilla/show_bug.cgi?id=65769
--- Comment #39 from Ruediger Pluem ---
Further gdb commands:
set $i=0
while ($iparent[$i++]
end
set $i=0
while($iservers[$i][$j++]
end
set $i=$i+1
end
--
You are receiving this mail because:
You are the assignee for the bug.
--
https://bz.apache.org/bugzilla/show_bug.cgi?id=65769
--- Comment #38 from Ruediger Pluem ---
Please use the core dump you captured of such a process and issue the following
gdb commands:
print *retained
print *(retained->idle_spawn_rate)
print *(retained->mpm)
--
You are receiving this mail be
https://bz.apache.org/bugzilla/show_bug.cgi?id=65769
--- Comment #37 from Teodor Milkov ---
Exactly, yes, that's what we are seeing -- just the parent process and no
workers for (at least) several minutes until the alarms ring and web server is
manually restarted.
--
You are receiving this mail
https://bz.apache.org/bugzilla/show_bug.cgi?id=65769
--- Comment #36 from Ruediger Pluem ---
Thanks. There could be some delay (1 or 2 secs) in restarting crashed
processes, but it should not remain without processes "forever". As far as I
understand the crashed processes never get replaced and y
https://bz.apache.org/bugzilla/show_bug.cgi?id=65769
--- Comment #35 from Teodor Milkov ---
(In reply to Ruediger Pluem from comment #34)
> (In reply to Teodor Milkov from comment #33)
> > Crashing child turned out to be caused by bad mod_security rule (at least in
> > one of the cases). It looks
https://bz.apache.org/bugzilla/show_bug.cgi?id=65769
--- Comment #34 from Ruediger Pluem ---
(In reply to Teodor Milkov from comment #33)
> Crashing child turned out to be caused by bad mod_security rule (at least in
> one of the cases). It looks the crash is unrelated, but newer apache is not
>
https://bz.apache.org/bugzilla/show_bug.cgi?id=65769
--- Comment #33 from Teodor Milkov ---
Crashing child turned out to be caused by bad mod_security rule (at least in
one of the cases). It looks the crash is unrelated, but newer apache is not
recovering from the situation.
--
You are receivin
https://bz.apache.org/bugzilla/show_bug.cgi?id=65769
Romain Lapoux changed:
What|Removed |Added
CC||ma...@manusfreedom.com
--
You are rec
https://bz.apache.org/bugzilla/show_bug.cgi?id=65769
--- Comment #32 from Teodor Milkov ---
1. I believe the main process is not multi-threaded. Just in case I've run
"thread apply all bt full" on the core file I have from the master process and
it looks the same as "bt full".
2/3: The crashed p
https://bz.apache.org/bugzilla/show_bug.cgi?id=65769
--- Comment #31 from Ruediger Pluem ---
I think we need:
1. thread apply all bt full from the main process.
2. thread apply all bt full from one of the "fat" processes.
3. thread apply all bt full from one of the crashed proceses.
--
You are
https://bz.apache.org/bugzilla/show_bug.cgi?id=65769
--- Comment #30 from Luke-Jr ---
Can confirm my error_log also has a segfault at least a few times most days.
Should we reopen this bug, or create a new one?
--
You are receiving this mail because:
You are the assignee for the bug.
-
https://bz.apache.org/bugzilla/show_bug.cgi?id=65769
--- Comment #29 from Teodor Milkov ---
I finally managed to run a debug version and save a dump with gcore.
Here's how process list looks usually on this server:
USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND
root
https://bz.apache.org/bugzilla/show_bug.cgi?id=65769
--- Comment #28 from Ruediger Pluem ---
(In reply to Yann Ylavic from comment #26)
> If it reproduces could you please:
>
> $ gdb /path/to/httpd -p
> (gdb) set logging on
> (gdb) set logging file /tmp/httpd-backtrace.log
> (gdb) thread apply
https://bz.apache.org/bugzilla/show_bug.cgi?id=65769
--- Comment #27 from Teodor Milkov ---
(In reply to Yann Ylavic from comment #26)
> If it reproduces could you please:
> ...
We were in a hurry to get something working and so we have reverted to using
2.4.51 + mod_h2 2.0.2. We may try again 2
https://bz.apache.org/bugzilla/show_bug.cgi?id=65769
--- Comment #26 from Yann Ylavic ---
If it reproduces could you please:
$ gdb /path/to/httpd -p
(gdb) set logging on
(gdb) set logging file /tmp/httpd-backtrace.log
(gdb) thread apply all bt full
and attach "httpd-backtrace.log" here?
( is t
https://bz.apache.org/bugzilla/show_bug.cgi?id=65769
--- Comment #25 from Teodor Milkov ---
Anybody still having this issue?
Yesterday I've upgraded from 2.4.51 to 2.4.53 and started experiencing similar
symptoms. Once in a while httpd just ceases to accept new connections. On a
fleet of about 1
https://bz.apache.org/bugzilla/show_bug.cgi?id=65769
--- Comment #24 from Luke-Jr ---
(In reply to Yann Ylavic from comment #22)
> (In reply to Luke-Jr from comment #21)
> >
> > Looking at the changes in r1896505, I suspect it may not fix it, because if
> > I attach during the problem condition:
https://bz.apache.org/bugzilla/show_bug.cgi?id=65769
Yann Ylavic changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bz.apache.org/bugzilla/show_bug.cgi?id=65769
--- Comment #22 from Yann Ylavic ---
(In reply to Luke-Jr from comment #21)
>
> Looking at the changes in r1896505, I suspect it may not fix it, because if
> I attach during the problem condition:
>
> (gdb) print listensocks_disabled
> $2 = 0
https://bz.apache.org/bugzilla/show_bug.cgi?id=65769
Luke-Jr changed:
What|Removed |Added
CC||luke-jr+apachebugs@utopios.
https://bz.apache.org/bugzilla/show_bug.cgi?id=65769
NathanFoley changed:
What|Removed |Added
CC||nfo...@tucasi.com
--
You are receiving
https://bz.apache.org/bugzilla/show_bug.cgi?id=65769
--- Comment #20 from Stefan Eissing ---
I plan to make a release candidate on Monday, March 7th. Giving that all goes
well, that should come out on Thursday, March 10th.
--
You are receiving this mail because:
You are the assignee for the bug
https://bz.apache.org/bugzilla/show_bug.cgi?id=65769
--- Comment #19 from Szymon Żogała ---
Hi, is there any news about the next release?
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscrib
https://bz.apache.org/bugzilla/show_bug.cgi?id=65769
Szymon Żogała changed:
What|Removed |Added
CC||szymek@gmail.com
--
You are recei
https://bz.apache.org/bugzilla/show_bug.cgi?id=65769
--- Comment #18 from Stefan Eissing ---
It seems highly likely that we do a release this month.
--
You are receiving this mail because:
You are the assignee for the bug.
-
To
https://bz.apache.org/bugzilla/show_bug.cgi?id=65769
--- Comment #17 from Jörg Meltzer ---
Hi,
this is affecting us in production.
Do we know already when there is a next release?
--
You are receiving this mail because:
You are the assignee for the bug.
-
https://bz.apache.org/bugzilla/show_bug.cgi?id=65769
Yann Ylavic changed:
What|Removed |Added
CC||vshe...@epiphan.com
--- Comment #16 from
https://bz.apache.org/bugzilla/show_bug.cgi?id=65769
Yann Ylavic changed:
What|Removed |Added
Keywords||FixedInTrunk
--- Comment #15 from Yann Y
https://bz.apache.org/bugzilla/show_bug.cgi?id=65769
--- Comment #14 from ldeliso ---
Yann: Yes, I confirm that the last attached patch fixes the issue.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bz.apache.org/bugzilla/show_bug.cgi?id=65769
--- Comment #13 from Yann Ylavic ---
(In reply to asf from comment #12)
> There were a lot of changes to server/mpm/event/event.c from Apache 2.4.51
> to Apache 2.4.52 - are you sure none of those changes is causing this issue?
Sure it's one o
https://bz.apache.org/bugzilla/show_bug.cgi?id=65769
--- Comment #12 from a...@spareknet.org ---
There were a lot of changes to server/mpm/event/event.c from Apache 2.4.51 to
Apache 2.4.52 - are you sure none of those changes is causing this issue?
All setups and configurations seem to work fine
https://bz.apache.org/bugzilla/show_bug.cgi?id=65769
Yann Ylavic changed:
What|Removed |Added
Attachment #38146|0 |1
is obsolete|
https://bz.apache.org/bugzilla/show_bug.cgi?id=65769
--- Comment #10 from ldeliso ---
Created attachment 38148
--> https://bz.apache.org/bugzilla/attachment.cgi?id=38148&action=edit
error_log_28122021
I applied the patch and can still reproduce the issue. The server ceased to
accept requests j
https://bz.apache.org/bugzilla/show_bug.cgi?id=65769
--- Comment #9 from Yann Ylavic ---
Created attachment 38147
--> https://bz.apache.org/bugzilla/attachment.cgi?id=38147&action=edit
Same without debug traces
--
You are receiving this mail because:
You are the assignee for the bug.
https://bz.apache.org/bugzilla/show_bug.cgi?id=65769
--- Comment #8 from Yann Ylavic ---
Created attachment 38146
--> https://bz.apache.org/bugzilla/attachment.cgi?id=38146&action=edit
server_main_loop to decrement active_daemons for exited children with quiescing
== 1 too
Could you please try
https://bz.apache.org/bugzilla/show_bug.cgi?id=65769
ldeliso changed:
What|Removed |Added
Status|NEEDINFO|NEW
--
You are receiving this mail because:
https://bz.apache.org/bugzilla/show_bug.cgi?id=65769
--- Comment #7 from ldeliso ---
Created attachment 38145
--> https://bz.apache.org/bugzilla/attachment.cgi?id=38145&action=edit
apache installation details
@Eric: when the child process hangs, it's immediately terminated so no luck in
tracin
https://bz.apache.org/bugzilla/show_bug.cgi?id=65769
--- Comment #6 from Yann Ylavic ---
Created attachment 38144
--> https://bz.apache.org/bugzilla/attachment.cgi?id=38144&action=edit
Use _exit() in clean_child_exit()
If the issue is of the atexit() kind, this patch should help too, does it?
https://bz.apache.org/bugzilla/show_bug.cgi?id=65769
Eric Covener changed:
What|Removed |Added
Status|NEW |NEEDINFO
--- Comment #5 from Eric Coven
https://bz.apache.org/bugzilla/show_bug.cgi?id=65769
--- Comment #4 from ldeliso ---
Created attachment 38143
--> https://bz.apache.org/bugzilla/attachment.cgi?id=38143&action=edit
error log 27122021
Below you can find the logs after increasing the debug level. The configuration
is the one I p
https://bz.apache.org/bugzilla/show_bug.cgi?id=65769
--- Comment #3 from Yann Ylavic ---
(In reply to Yann Ylavic from comment #2)
> Please add "LogLevel mpm_event:trace6" in the global configuration
"LogLevel mpm_event:trace5" should be enough and much less verbose.
--
You are receiving this
https://bz.apache.org/bugzilla/show_bug.cgi?id=65769
--- Comment #2 from Yann Ylavic ---
Please add "LogLevel mpm_event:trace6" in the global configuration (after the
other LogLevel, if any) and attach the error_log file here.
I tried to reproduce with ab and the default configuration (also with
https://bz.apache.org/bugzilla/show_bug.cgi?id=65769
--- Comment #1 from ldeliso ---
I experienced this issue as well (in all cases I was using the event MPM):
apache stops accepting any connection because no listener thread is running. No
events are reported in the error log and downgrading to a
46 matches
Mail list logo