https://bz.apache.org/bugzilla/show_bug.cgi?id=65769 --- Comment #29 from Teodor Milkov <zimage@icdsoft.com> ---
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 %MEM VSZ RSS TTY STAT START TIME COMMAND
root 50551 0.0 0.9 119520 57908 ? Ss Mar30 0:23
/apache/bin/httpd -k start
apache 55583 0.0 0.4 118344 26592 ? S 12:15 0:00 \_
/apache/bin/httpd -k start
apache 55584 0.0 0.4 119520 26948 ? S 12:15 0:00 \_
/apache/bin/httpd -k start
apache 55585 5.2 0.8 9374960 49764 ? Sl 12:15 0:00 \_
/apache/bin/httpd -k start
apache 56594 1.3 0.6 9331520 42000 ? Sl 12:15 0:00 \_
/apache/bin/httpd -k start
And here's how it looked when stuck:
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 13105 0.0 0.9 119384 57524 ? Ss 03:08 0:02
/apache/bin/httpd -k start
apache 28298 0.0 0.4 118216 27392 ? S 06:00 0:00 \_
/apache/bin/httpd -k start
apache 28299 0.0 0.4 119376 26624 ? S 06:00 0:00 \_
/apache/bin/httpd -k start
So, there are: 1. the master (root) process, 2. two "thin" processes which
probably take care of the cgi (we use suexec) and 3. two "fat" processes which
are the mpm_event workers.
Here's bt of the root process. Please let me know if I should do something
else:
gdb ./httpd-2.4.53-debug core.13105
(gdb) bt full
#0 0x000072a77d0b7a27 in __GI___select (nfds=0, readfds=0x0, writefds=0x0,
exceptfds=0x0, timeout=0x7b4d48201f70) at
../sysdeps/unix/sysv/linux/select.c:41
resultvar = 18446744073709551102
sc_ret = <optimized out>
#1 0x000072a77d1d3535 in apr_sleep () from
/usr/lib/x86_64-linux-gnu/libapr-1.so.0
No symbol table info available.
#2 0x00001e99ee736b41 in ap_wait_or_timeout (status=0x7b4d48202024,
exitcode=0x7b4d48202020, ret=0x7b4d48202000, p=0x72a77d8c4028,
s=0x72a77cd6cb48) at mpm_common.c:205
rv = 70006
#3 0x00001e99ee81d8d9 in server_main_loop (remaining_children_to_start=0) at
event.c:3026
num_buckets = 1
child_slot = 0
exitwhy = APR_PROC_SIGNAL
status = 11
processed_status = 0
pid = {pid = -1, in = 0x1e99ee769e1e <ap_log_command_line+327>, out =
0x1e99ee82b6dd, err = 0x72a778d487e8}
i = 1
#4 0x00001e99ee81df29 in event_run (_pconf=0x72a77d8c4028,
plog=0x72a77cd5f028, s=0x72a77cd6cb48) at event.c:3204
num_buckets = 1
remaining_children_to_start = 0
i = 0
#5 0x00001e99ee735f4d in ap_run_mpm (pconf=0x72a77d8c4028,
plog=0x72a77cd5f028, s=0x72a77cd6cb48) at mpm_common.c:95
pHook = 0x72a77a9082d0
n = 0
rv = -1
#6 0x00001e99ee72c0cd in main (argc=3, argv=0x7b4d48202308) at main.c:841
c = 0 '\000'
showcompile = 0
showdirectives = 0
confname = 0x1e99ee822d43 "conf/httpd.conf"
def_server_root = 0x1e99ee822d53 "/apache"
temp_error_log = 0x0
error = 0x0
process = 0x72a77d8c6118
pconf = 0x72a77d8c4028
plog = 0x72a77cd5f028
ptemp = 0x72a77cd57028
pcommands = 0x72a77cd79028
opt = 0x72a77cd79118
rv = 0
mod = 0x1e99ee86d9e8 <ap_prelinked_modules+328>
opt_arg = 0x7b4d48202170 "\250\002\215}\247r"
signal_server = 0x1e99ee77446e <ap_signal_server>
rc = 0
Looking at this backtrace I noticed it mentions signal 11 and looking in the
error_log there's indeed this:
[Wed Mar 30 06:04:37 2022] [notice] [pid 13105] mpm_unix.c(436): AH00052: child
pid 28302 exit signal Segmentation fault (11)
Now looking across error logs of all our servers it's not unusual to see this
segfault on a daily basis. Apparently, 2.4.51 handles the child crashing
gracefully, while 2.4.53 gets stuck.
It's another question why the segfault and I'm going to investigate this one
too, but IMO it'd be great if we can get back to the graceful behaviour from
pre 2.4.53.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org