mod_qos crashes Apache 2.4 on graceful restart

K

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:
Code: 
[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.
 
kjpetrie said:
A quick look at php-fpm suggests it could be a security nightmare for self-hosted website admins.
Click to expand...
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)
 
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.
 
Not sure if it's directly related, but I had to stop using graceful with mod_php 3+ years ago:

R

Thread 'apachectl graceful causes SIGSEGV with latest PHP 8.1.x and PHP 8.2.x'

Wondering if anyone else seeing this?

Building from ports (just because that's what I've always done) - FreeBSD 13.1 (or 13.2) on amd64, Apache 2.4.56 or 2.4.57, PHP 8.2.4 (and 8.2.5) both exhibit the behaviour, as do 8.1.17 and 8.1.18.

mod_php82 (or 81).

Noticed when logs rotated, but further digging showing it's effectively the apachectl graceful causing my problems. After an apachectl graceful you'll have stopped serving web pages. apachectl restart is fine.

Apache and mod_php82 were fine, so I started adding a few extensions and got it to start happening. Thought it was cURL for...
  • Thanks
 
It certainly looks like another manifestation of the same issue. Some Apache modules clearly disagree with each other and it's a bit of a lottery, sometimes even depending on start order by the look of it. I've always thought of Apache as a rock-solid platform but evidently adding modules can upset that.

As I have a script looping continuously monitoring the server and its logs it's no hardship to have it check Apache is still running and start it if necessary and that's probably the best I can do for now.
 
You must log in or register to reply here.
Back
Top