mod_qos crashes Apache 2.4 on graceful restart

[kjpetrie]

I have installed www/mod_qos to enable me to resist robotic attempts to find weaknesses in my set-up by spamming with hundreds of requests for hacks at a time by limiting accesses and connections from any one IP at a time.

Unfortunately, I have a script which checks my certificate for renewal every morning which requests a graceful restart of Apache and with mod_qos installed that crashes Apache. Apache will restart fully but not gracefully.

The only clue is three lines in /var/log/httpd-error.log:

[Tue Oct 06 10:37:47.289645 2026] [mpm_prefork:notice] [pid 3983] AH00171: Graceful restart requested, doing restart
[Tue Oct 06 10:37:47.673417 2026] [qos:notice] [pid 3983] mod_qos(009): loaded MPM is 'prefork' but mod_qos should be used with MPM 'Worker' or 'Event' only.
[Tue Oct 06 10:37:47.676166 2026] [qos:emerg] [pid 3983] mod_qos(004): failed to create mutex (ACT)(/tmp/K075352263.mod_qos): File exists

Unfortunately, my sites rely heavily on PHP scripting and Event and Worker are incompatible with
www/mod_php. A quick look at php-fpm suggests it could be a security nightmare for self-hosted website admins.

Am I right in thinking mod_php and mod_qos cannot be used together, or do I just have to avoid graceful restarts?

Update: mod_qos seems to work as long as Apache doesn't attempt a graceful restart. As I can't guarantee to ensure nothing triggers that (something unidentified sent it a SIGHUP at noon today - maybe a newsyslog event or similar) and I have a script monitoring its logs approximately every second, I worked around the problem by adding a status check and conditional start if Apache is not running to that script. This should keep site down time to about a second, which should have minimal impact on people accessing it.

It would still be good to know whether there's a proper solution though. Workarounds are always second best.

 

[Espionage724]

A quick look at php-fpm suggests it could be a security nightmare for self-hosted website admins.

I figured it better to separate PHP and webserver executables (on Windows nginx and php handle a few Defender mitigations differently; one didn't like CFG or something) so if something exploited PHP, it wouldn't necessarily affect the webserver part.

Iirc like 10 years ago nginx + php-fpm could handle more requests/thread better vs Apache with PHP built-in. I only tried Apache briefly back then before switching to nginx but it really seems PHP should be separate (I like the concept of nginx serving statics and each site having its own PHP-FPM instance; if one FPM goes down or gets flooded it won't affect the others and nginx can quick-serve a 502)

 

[kjpetrie]

Well, maybe so, but I don't want to go into unknown territory more than I can avoid. I've been using Apache for about 30 years now, and I'm thoroughly used to it.

However, with the rise of AI it's clear I'm not just up against script kiddies trying to find weaknesses but consistent automated attacks from systems designed to try and learn very quickly, which will find a way in if there is one. I therefore need my server to spot and shut down any nefarious activity as quickly as possible to keep these malicious bots firmly locked out, while still letting human beings with web browsers in.

Rate-limiting and activity-based packet filtering are two techniques I'm trying at the moment but I really don't want to change my whole basic configuration to do it.