Mailing List Archive

old gen workers sticking around post 2.4.49
An Apache/2.4.56 (Unix) server using "event" MPM sometimes does not clean up an
idle old gen worker after "apachectl graceful". The old gen worker continues to
take requests. The syslog contains AH00646 errors thrown when the old gen worker
handles a request and attempts to record the transfer on a closed pipe.

I cannot reproduce "at will", but the problem does reappear frequently.

Normally, "apachectl graceful" is executed by the daily "dehydrated" ACME client
"deploy_cert" hook, which is called when a new certificate is produced. If
multiple certificates age out on the same day, this can result in as many
rapid-fire back-to-back "apachectl graceful" calls as there are certificates to
regen. Manually running "dehydrated -c -x" (force-regen all certificates at
once) sometimes recreates the problem, but not always.

Once the condition is present, the first "apachectl stop" stops new gen worker
but not old gen worker, and the second "apachectl stop" reports the PID file is
gone and does nothing. To bring completely down, one can "pkill httpd", or the
moral equivalent.

This is a light-duty personal server. Traffic is very light -- 500 requests per
hour, mostly static with a bit of PHP. server_status generally shows all
scoreboard slots either open (.) or waiting for connection (_), except the
server_status request itself (W).

When server_status is handled by the new gen worker, the old gen worker is shown
as "Stopping: no (old gen)". And (strangely to me), when server_status is
handled by the old gen worker, the new gen worker is shown as "Stopping: no (old
gen)".

I see other people have reported similar problems in the past. All seem to point
to a bug tracked as Bugzilla 63169 and fixed in 2.4.49. This server is at
2.4.56. It is Slackware 15.0's stock httpd.

Loaded Modules
core.c, event.c, http_core.c, mod_alias.c, mod_authz_core.c, mod_authz_host.c,
mod_autoindex.c, mod_cgid.c, mod_dir.c, mod_headers.c, mod_info.c,
mod_log_config.c, mod_mime.c, mod_negotiation.c, mod_php7.c, mod_reqtimeout.c,
mod_so.c, mod_socache_shmcb.c, mod_ssl.c, mod_status.c, mod_unixd.c

Configuration of event.c is:
Listen 80
Listen 443
MaxRequestWorkers 25

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: old gen workers sticking around post 2.4.49 [ In reply to ]
Why are you using the event mpm with mod_php? This isn't recommended.

On Thu, Mar 23, 2023 at 3:37?PM <metaed@newjersey.metaed.com.invalid> wrote:

> An Apache/2.4.56 (Unix) server using "event" MPM sometimes does not clean
> up an
> idle old gen worker after "apachectl graceful". The old gen worker
> continues to
> take requests. The syslog contains AH00646 errors thrown when the old gen
> worker
> handles a request and attempts to record the transfer on a closed pipe.
>
> I cannot reproduce "at will", but the problem does reappear frequently.
>
> Normally, "apachectl graceful" is executed by the daily "dehydrated" ACME
> client
> "deploy_cert" hook, which is called when a new certificate is produced. If
> multiple certificates age out on the same day, this can result in as many
> rapid-fire back-to-back "apachectl graceful" calls as there are
> certificates to
> regen. Manually running "dehydrated -c -x" (force-regen all certificates at
> once) sometimes recreates the problem, but not always.
>
> Once the condition is present, the first "apachectl stop" stops new gen
> worker
> but not old gen worker, and the second "apachectl stop" reports the PID
> file is
> gone and does nothing. To bring completely down, one can "pkill httpd", or
> the
> moral equivalent.
>
> This is a light-duty personal server. Traffic is very light -- 500
> requests per
> hour, mostly static with a bit of PHP. server_status generally shows all
> scoreboard slots either open (.) or waiting for connection (_), except the
> server_status request itself (W).
>
> When server_status is handled by the new gen worker, the old gen worker is
> shown
> as "Stopping: no (old gen)". And (strangely to me), when server_status is
> handled by the old gen worker, the new gen worker is shown as "Stopping:
> no (old
> gen)".
>
> I see other people have reported similar problems in the past. All seem to
> point
> to a bug tracked as Bugzilla 63169 and fixed in 2.4.49. This server is at
> 2.4.56. It is Slackware 15.0's stock httpd.
>
> Loaded Modules
> core.c, event.c, http_core.c, mod_alias.c, mod_authz_core.c,
> mod_authz_host.c,
> mod_autoindex.c, mod_cgid.c, mod_dir.c, mod_headers.c, mod_info.c,
> mod_log_config.c, mod_mime.c, mod_negotiation.c, mod_php7.c,
> mod_reqtimeout.c,
> mod_so.c, mod_socache_shmcb.c, mod_ssl.c, mod_status.c, mod_unixd.c
>
> Configuration of event.c is:
> Listen 80
> Listen 443
> MaxRequestWorkers 25
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
>
Re: old gen workers sticking around post 2.4.49 [ In reply to ]
Frank Gingras <thumbs@apache.org> wrote:
> Why are you using the event mpm with mod_php? This isn't recommended.

I don't know enough to disagree, or say whether this is causing the problem. I
can tell you my weak reasons:

Out of the box, Slackware 15.0 httpd loads the event MPM, and its LAMP how-to
gives directions for enabling PHP that do not entail switching MPMs, seemingly
because its PHP is thread safe:

$ php -i | grep Thread
Thread Safety => enabled
Thread API => POSIX Threads

From my reading, prefork MPM gets recommended over a threaded MPM with mod_php
because thread safety is hard. The PHP FAQ recommends against a threaded MPM in
a production environment. But the Apache wiki PHP article actually prefers a
threaded MPM over prefork MPM for performance reasons, in the rare case that
one's Linux distribution ships a threaded MPM, which apparently mine does.

The reports I've seen of errors running a thread-unsafe PHP with the event MPM
involve segfaults, which is not what I'm seeing. My problem looks a bit more
like a race condition in graceful restarts.

To sum up, laziness (not deviating from presets) plus the Apache recommendation
are my reasons, which as I've said are weak.

I'll try to reproduce the problem without mod_php. The good news is it will only
irritate one user. The bad news is it's my wife.

If mod_php turns out to be the culprit, I'll try php-fpm, which seems to also be
preinstalled by Slackware 15.0, but not discussed in the Slackware LAMP how-to.

Cheers! Edward

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: old gen workers sticking around post 2.4.49 [ In reply to ]
A few weird things:

- the old gen should not be able to accept new connections
- generally if it's left running, I would want to look at what
threads were left running (pstack or often better the few gdb commands
here: https://httpd.apache.org/dev/debugging.html#backtrace). Often
something will stick out as spinning, or in some kind of blocking I/O
with no timeout.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: old gen workers sticking around post 2.4.49 [ In reply to ]
Eric Covener <covener@gmail.com> wrote:
> - the old gen should not be able to accept new connections
> - generally if it's left running, I would want to look at what
> threads were left running (pstack or often better the few gdb commands
> here: https://httpd.apache.org/dev/debugging.html#backtrace

Here is the gdb session against process 31708, the old-gen worker, running the
stock Slackware 15.0 httpd executable.

# gdb httpd 31708
GNU gdb (GDB) 11.2
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-slackware-linux".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from httpd...
(No debugging symbols found in httpd)
Attaching to program: /usr/sbin/httpd, process 31708
[New LWP 31736]
[New LWP 31737]
[New LWP 31738]
[New LWP 31739]
[New LWP 31740]
[New LWP 31741]
[New LWP 31742]
[New LWP 31743]
[New LWP 31744]
[New LWP 31745]
[New LWP 31746]
[New LWP 31747]
[New LWP 31748]
[New LWP 31749]
[New LWP 31750]
[New LWP 31751]
[New LWP 31752]
[New LWP 31753]
[New LWP 31754]
[New LWP 31755]
[New LWP 31756]
[New LWP 31757]
[New LWP 31758]
[New LWP 31759]
[New LWP 31760]
[New LWP 31761]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
0x00007f12c8d573fc in read () from /lib64/libpthread.so.0
(gdb) where
#0 0x00007f12c8d573fc in read () from /lib64/libpthread.so.0
#1 0x00005611890d9d27 in ap_mpm_podx_check ()
#2 0x00007f12c61a187f in ?? () from /usr/lib64/httpd/modules/mod_mpm_event.so
#3 0x00007f12c61a1cda in ?? () from /usr/lib64/httpd/modules/mod_mpm_event.so
#4 0x00007f12c61a1d51 in ?? () from /usr/lib64/httpd/modules/mod_mpm_event.so
#5 0x00007f12c61a2812 in ?? () from /usr/lib64/httpd/modules/mod_mpm_event.so
#6 0x00005611890adf60 in ap_run_mpm ()
#7 0x00005611890a6060 in main ()
(gdb) thread apply all bt

Thread 27 (Thread 0x7f12a9feb640 (LWP 31761) "httpd"):
#0 0x00007f12c8c6d7d6 in epoll_wait () from /lib64/libc.so.6
#1 0x00007f12c8e06fec in ?? () from /usr/lib64/libapr-1.so.0
#2 0x00007f12c61a4368 in ?? () from /usr/lib64/httpd/modules/mod_mpm_event.so
#3 0x00007f12c8d4de45 in start_thread () from /lib64/libpthread.so.0
#4 0x00007f12c8c6d4af in clone () from /lib64/libc.so.6

Thread 26 (Thread 0x7f12aa7ec640 (LWP 31760) "httpd"):
#0 0x00007f12c8d5a1ae in __futex_abstimed_wait_cancelable64 () from /lib64/libpthread.so.0
#1 0x00007f12c8d53d41 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#2 0x00005611890dab85 in ap_queue_pop_something ()
#3 0x00007f12c61a5cbc in ?? () from /usr/lib64/httpd/modules/mod_mpm_event.so
#4 0x00007f12c8d4de45 in start_thread () from /lib64/libpthread.so.0
#5 0x00007f12c8c6d4af in clone () from /lib64/libc.so.6

Thread 25 (Thread 0x7f12aafed640 (LWP 31759) "httpd"):
#0 0x00007f12c8d5a1ae in __futex_abstimed_wait_cancelable64 () from /lib64/libpthread.so.0
#1 0x00007f12c8d53d41 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#2 0x00005611890dab85 in ap_queue_pop_something ()
#3 0x00007f12c61a5cbc in ?? () from /usr/lib64/httpd/modules/mod_mpm_event.so
#4 0x00007f12c8d4de45 in start_thread () from /lib64/libpthread.so.0
#5 0x00007f12c8c6d4af in clone () from /lib64/libc.so.6

Thread 24 (Thread 0x7f12ab7ee640 (LWP 31758) "httpd"):
#0 0x00007f12c8d5a1ae in __futex_abstimed_wait_cancelable64 () from /lib64/libpthread.so.0
#1 0x00007f12c8d53d41 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#2 0x00005611890dab85 in ap_queue_pop_something ()
#3 0x00007f12c61a5cbc in ?? () from /usr/lib64/httpd/modules/mod_mpm_event.so
#4 0x00007f12c8d4de45 in start_thread () from /lib64/libpthread.so.0
#5 0x00007f12c8c6d4af in clone () from /lib64/libc.so.6

Thread 23 (Thread 0x7f12abfef640 (LWP 31757) "httpd"):
#0 0x00007f12c8d5a1ae in __futex_abstimed_wait_cancelable64 () from /lib64/libpthread.so.0
#1 0x00007f12c8d53d41 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#2 0x00005611890dab85 in ap_queue_pop_something ()
#3 0x00007f12c61a5cbc in ?? () from /usr/lib64/httpd/modules/mod_mpm_event.so
#4 0x00007f12c8d4de45 in start_thread () from /lib64/libpthread.so.0
#5 0x00007f12c8c6d4af in clone () from /lib64/libc.so.6

Thread 22 (Thread 0x7f12ac7f0640 (LWP 31756) "httpd"):
#0 0x00007f12c8d5a1ae in __futex_abstimed_wait_cancelable64 () from /lib64/libpthread.so.0
#1 0x00007f12c8d53d41 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#2 0x00005611890dab85 in ap_queue_pop_something ()
#3 0x00007f12c61a5cbc in ?? () from /usr/lib64/httpd/modules/mod_mpm_event.so
#4 0x00007f12c8d4de45 in start_thread () from /lib64/libpthread.so.0
#5 0x00007f12c8c6d4af in clone () from /lib64/libc.so.6

Thread 21 (Thread 0x7f12acff1640 (LWP 31755) "httpd"):
#0 0x00007f12c8d5a1ae in __futex_abstimed_wait_cancelable64 () from /lib64/libpthread.so.0
#1 0x00007f12c8d53d41 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#2 0x00005611890dab85 in ap_queue_pop_something ()
#3 0x00007f12c61a5cbc in ?? () from /usr/lib64/httpd/modules/mod_mpm_event.so
#4 0x00007f12c8d4de45 in start_thread () from /lib64/libpthread.so.0
#5 0x00007f12c8c6d4af in clone () from /lib64/libc.so.6

Thread 20 (Thread 0x7f12ad7f2640 (LWP 31754) "httpd"):
#0 0x00007f12c8d5a1ae in __futex_abstimed_wait_cancelable64 () from /lib64/libpthread.so.0
#1 0x00007f12c8d53d41 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#2 0x00005611890dab85 in ap_queue_pop_something ()
#3 0x00007f12c61a5cbc in ?? () from /usr/lib64/httpd/modules/mod_mpm_event.so
#4 0x00007f12c8d4de45 in start_thread () from /lib64/libpthread.so.0
#5 0x00007f12c8c6d4af in clone () from /lib64/libc.so.6

Thread 19 (Thread 0x7f12adff3640 (LWP 31753) "httpd"):
#0 0x00007f12c8d5a1ae in __futex_abstimed_wait_cancelable64 () from /lib64/libpthread.so.0
#1 0x00007f12c8d53d41 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#2 0x00005611890dab85 in ap_queue_pop_something ()
#3 0x00007f12c61a5cbc in ?? () from /usr/lib64/httpd/modules/mod_mpm_event.so
#4 0x00007f12c8d4de45 in start_thread () from /lib64/libpthread.so.0
#5 0x00007f12c8c6d4af in clone () from /lib64/libc.so.6

Thread 18 (Thread 0x7f12ae7f4640 (LWP 31752) "httpd"):
#0 0x00007f12c8d5a1ae in __futex_abstimed_wait_cancelable64 () from /lib64/libpthread.so.0
#1 0x00007f12c8d53d41 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#2 0x00005611890dab85 in ap_queue_pop_something ()
#3 0x00007f12c61a5cbc in ?? () from /usr/lib64/httpd/modules/mod_mpm_event.so
#4 0x00007f12c8d4de45 in start_thread () from /lib64/libpthread.so.0
#5 0x00007f12c8c6d4af in clone () from /lib64/libc.so.6

Thread 17 (Thread 0x7f12aeff5640 (LWP 31751) "httpd"):
#0 0x00007f12c8d5a1ae in __futex_abstimed_wait_cancelable64 () from /lib64/libpthread.so.0
#1 0x00007f12c8d53d41 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#2 0x00005611890dab85 in ap_queue_pop_something ()
#3 0x00007f12c61a5cbc in ?? () from /usr/lib64/httpd/modules/mod_mpm_event.so
#4 0x00007f12c8d4de45 in start_thread () from /lib64/libpthread.so.0
#5 0x00007f12c8c6d4af in clone () from /lib64/libc.so.6

Thread 16 (Thread 0x7f12af7f6640 (LWP 31750) "httpd"):
#0 0x00007f12c8d5a1ae in __futex_abstimed_wait_cancelable64 () from /lib64/libpthread.so.0
#1 0x00007f12c8d53d41 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#2 0x00005611890dab85 in ap_queue_pop_something ()
#3 0x00007f12c61a5cbc in ?? () from /usr/lib64/httpd/modules/mod_mpm_event.so
#4 0x00007f12c8d4de45 in start_thread () from /lib64/libpthread.so.0
#5 0x00007f12c8c6d4af in clone () from /lib64/libc.so.6

Thread 15 (Thread 0x7f12afff7640 (LWP 31749) "httpd"):
#0 0x00007f12c8d5a1ae in __futex_abstimed_wait_cancelable64 () from /lib64/libpthread.so.0
#1 0x00007f12c8d53d41 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#2 0x00005611890dab85 in ap_queue_pop_something ()
#3 0x00007f12c61a5cbc in ?? () from /usr/lib64/httpd/modules/mod_mpm_event.so
#4 0x00007f12c8d4de45 in start_thread () from /lib64/libpthread.so.0
#5 0x00007f12c8c6d4af in clone () from /lib64/libc.so.6

Thread 14 (Thread 0x7f12b07f8640 (LWP 31748) "httpd"):
#0 0x00007f12c8d5a1ae in __futex_abstimed_wait_cancelable64 () from /lib64/libpthread.so.0
#1 0x00007f12c8d53d41 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#2 0x00005611890dab85 in ap_queue_pop_something ()
#3 0x00007f12c61a5cbc in ?? () from /usr/lib64/httpd/modules/mod_mpm_event.so
#4 0x00007f12c8d4de45 in start_thread () from /lib64/libpthread.so.0
#5 0x00007f12c8c6d4af in clone () from /lib64/libc.so.6

Thread 13 (Thread 0x7f12b0ff9640 (LWP 31747) "httpd"):
#0 0x00007f12c8d5a1ae in __futex_abstimed_wait_cancelable64 () from /lib64/libpthread.so.0
#1 0x00007f12c8d53d41 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#2 0x00005611890dab85 in ap_queue_pop_something ()
#3 0x00007f12c61a5cbc in ?? () from /usr/lib64/httpd/modules/mod_mpm_event.so
#4 0x00007f12c8d4de45 in start_thread () from /lib64/libpthread.so.0
#5 0x00007f12c8c6d4af in clone () from /lib64/libc.so.6

Thread 12 (Thread 0x7f12b17fa640 (LWP 31746) "httpd"):
#0 0x00007f12c8d5a1ae in __futex_abstimed_wait_cancelable64 () from /lib64/libpthread.so.0
#1 0x00007f12c8d53d41 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#2 0x00005611890dab85 in ap_queue_pop_something ()
#3 0x00007f12c61a5cbc in ?? () from /usr/lib64/httpd/modules/mod_mpm_event.so
#4 0x00007f12c8d4de45 in start_thread () from /lib64/libpthread.so.0
#5 0x00007f12c8c6d4af in clone () from /lib64/libc.so.6

Thread 11 (Thread 0x7f12b1ffb640 (LWP 31745) "httpd"):
#0 0x00007f12c8d5a1ae in __futex_abstimed_wait_cancelable64 () from /lib64/libpthread.so.0
#1 0x00007f12c8d53d41 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#2 0x00005611890dab85 in ap_queue_pop_something ()
#3 0x00007f12c61a5cbc in ?? () from /usr/lib64/httpd/modules/mod_mpm_event.so
#4 0x00007f12c8d4de45 in start_thread () from /lib64/libpthread.so.0
#5 0x00007f12c8c6d4af in clone () from /lib64/libc.so.6

Thread 10 (Thread 0x7f12b27fc640 (LWP 31744) "httpd"):
#0 0x00007f12c8d5a1ae in __futex_abstimed_wait_cancelable64 () from /lib64/libpthread.so.0
#1 0x00007f12c8d53d41 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#2 0x00005611890dab85 in ap_queue_pop_something ()
#3 0x00007f12c61a5cbc in ?? () from /usr/lib64/httpd/modules/mod_mpm_event.so
#4 0x00007f12c8d4de45 in start_thread () from /lib64/libpthread.so.0
#5 0x00007f12c8c6d4af in clone () from /lib64/libc.so.6

Thread 9 (Thread 0x7f12b2ffd640 (LWP 31743) "httpd"):
#0 0x00007f12c8d5a1ae in __futex_abstimed_wait_cancelable64 () from /lib64/libpthread.so.0
#1 0x00007f12c8d53d41 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#2 0x00005611890dab85 in ap_queue_pop_something ()
#3 0x00007f12c61a5cbc in ?? () from /usr/lib64/httpd/modules/mod_mpm_event.so
#4 0x00007f12c8d4de45 in start_thread () from /lib64/libpthread.so.0
#5 0x00007f12c8c6d4af in clone () from /lib64/libc.so.6

Thread 8 (Thread 0x7f12b37fe640 (LWP 31742) "httpd"):
#0 0x00007f12c8d5a1ae in __futex_abstimed_wait_cancelable64 () from /lib64/libpthread.so.0
#1 0x00007f12c8d53d41 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#2 0x00005611890dab85 in ap_queue_pop_something ()
#3 0x00007f12c61a5cbc in ?? () from /usr/lib64/httpd/modules/mod_mpm_event.so
#4 0x00007f12c8d4de45 in start_thread () from /lib64/libpthread.so.0
#5 0x00007f12c8c6d4af in clone () from /lib64/libc.so.6

Thread 7 (Thread 0x7f12b3fff640 (LWP 31741) "httpd"):
#0 0x00007f12c8d5a1ae in __futex_abstimed_wait_cancelable64 () from /lib64/libpthread.so.0
#1 0x00007f12c8d53d41 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#2 0x00005611890dab85 in ap_queue_pop_something ()
#3 0x00007f12c61a5cbc in ?? () from /usr/lib64/httpd/modules/mod_mpm_event.so
#4 0x00007f12c8d4de45 in start_thread () from /lib64/libpthread.so.0
#5 0x00007f12c8c6d4af in clone () from /lib64/libc.so.6

Thread 6 (Thread 0x7f12b8b70640 (LWP 31740) "httpd"):
#0 0x00007f12c8d5a1ae in __futex_abstimed_wait_cancelable64 () from /lib64/libpthread.so.0
#1 0x00007f12c8d53d41 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#2 0x00005611890dab85 in ap_queue_pop_something ()
#3 0x00007f12c61a5cbc in ?? () from /usr/lib64/httpd/modules/mod_mpm_event.so
#4 0x00007f12c8d4de45 in start_thread () from /lib64/libpthread.so.0
#5 0x00007f12c8c6d4af in clone () from /lib64/libc.so.6

Thread 5 (Thread 0x7f12b9371640 (LWP 31739) "httpd"):
#0 0x00007f12c8d5a1ae in __futex_abstimed_wait_cancelable64 () from /lib64/libpthread.so.0
#1 0x00007f12c8d53d41 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#2 0x00005611890dab85 in ap_queue_pop_something ()
#3 0x00007f12c61a5cbc in ?? () from /usr/lib64/httpd/modules/mod_mpm_event.so
#4 0x00007f12c8d4de45 in start_thread () from /lib64/libpthread.so.0
#5 0x00007f12c8c6d4af in clone () from /lib64/libc.so.6

Thread 4 (Thread 0x7f12b9b72640 (LWP 31738) "httpd"):
#0 0x00007f12c8d5a1ae in __futex_abstimed_wait_cancelable64 () from /lib64/libpthread.so.0
#1 0x00007f12c8d53d41 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#2 0x00005611890dab85 in ap_queue_pop_something ()
#3 0x00007f12c61a5cbc in ?? () from /usr/lib64/httpd/modules/mod_mpm_event.so
#4 0x00007f12c8d4de45 in start_thread () from /lib64/libpthread.so.0
#5 0x00007f12c8c6d4af in clone () from /lib64/libc.so.6

Thread 3 (Thread 0x7f12ba373640 (LWP 31737) "httpd"):
#0 0x00007f12c8d5a1ae in __futex_abstimed_wait_cancelable64 () from /lib64/libpthread.so.0
#1 0x00007f12c8d53d41 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#2 0x00005611890dab85 in ap_queue_pop_something ()
#3 0x00007f12c61a5cbc in ?? () from /usr/lib64/httpd/modules/mod_mpm_event.so
#4 0x00007f12c8d4de45 in start_thread () from /lib64/libpthread.so.0
#5 0x00007f12c8c6d4af in clone () from /lib64/libc.so.6

Thread 2 (Thread 0x7f12bab74640 (LWP 31736) "httpd"):
#0 0x00007f12c8d5a1ae in __futex_abstimed_wait_cancelable64 () from /lib64/libpthread.so.0
#1 0x00007f12c8d53d41 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#2 0x00005611890dab85 in ap_queue_pop_something ()
#3 0x00007f12c61a5cbc in ?? () from /usr/lib64/httpd/modules/mod_mpm_event.so
#4 0x00007f12c8d4de45 in start_thread () from /lib64/libpthread.so.0
#5 0x00007f12c8c6d4af in clone () from /lib64/libc.so.6

Thread 1 (Thread 0x7f12c61cf7c0 (LWP 31708) "httpd"):
#0 0x00007f12c8d573fc in read () from /lib64/libpthread.so.0
#1 0x00005611890d9d27 in ap_mpm_podx_check ()
#2 0x00007f12c61a187f in ?? () from /usr/lib64/httpd/modules/mod_mpm_event.so
#3 0x00007f12c61a1cda in ?? () from /usr/lib64/httpd/modules/mod_mpm_event.so
#4 0x00007f12c61a1d51 in ?? () from /usr/lib64/httpd/modules/mod_mpm_event.so
#5 0x00007f12c61a2812 in ?? () from /usr/lib64/httpd/modules/mod_mpm_event.so
#6 0x00005611890adf60 in ap_run_mpm ()
#7 0x00005611890a6060 in main ()
(gdb) detach
Detaching from program: /usr/sbin/httpd, process 31708
[Inferior 1 (process 31708) detached]
(gdb) quit

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: old gen workers sticking around post 2.4.49 [ In reply to ]
I wrote:
> I'll try to reproduce the problem without mod_php.

Using "dehydrated -c -x" to drive my testing, I've hit the 7-day rate limit at
Let's Encrypt, so I'll have to come back to this.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: old gen workers sticking around post 2.4.49 [ In reply to ]
I wrote:
> I'll try to reproduce the problem without mod_php.
and:
> Using "dehydrated -c -x" to drive my testing, I've hit the 7-day rate limit at
> Let's Encrypt, so I'll have to come back to this.

I can reproduce the problem pretty easily with mod_php loaded. Unloaded, I have
been unable to reproduce it. I'll abandon that combination.

Given that this is a low-traffic server, I think my next step will be migrate to
prefork MPM, and if I run into performance issues, the step after that is
php-fpm. Does that plan make sense?

Cheers! Edward

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: old gen workers sticking around post 2.4.49 [ In reply to ]
I'd say much better to move to mpm_event and and php-fpm, ridding httpd of
PHP module and it's quirks in the process.

El mar, 11 abr 2023 23:24, <metaed@newjersey.metaed.com.invalid> escribió:

> I wrote:
> > I'll try to reproduce the problem without mod_php.
> and:
> > Using "dehydrated -c -x" to drive my testing, I've hit the 7-day rate
> limit at
> > Let's Encrypt, so I'll have to come back to this.
>
> I can reproduce the problem pretty easily with mod_php loaded. Unloaded, I
> have
> been unable to reproduce it. I'll abandon that combination.
>
> Given that this is a low-traffic server, I think my next step will be
> migrate to
> prefork MPM, and if I run into performance issues, the step after that is
> php-fpm. Does that plan make sense?
>
> Cheers! Edward
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
>
>
>