I have a PHP-under mod_fastcgi setup that's working quite nicely, except for one well-known quirk; fcgi-pm SIGTERMs the PHP processes when the Apache tree is being SIGUSR1d for a graceful reload. In result, people waiting for script results get a 5xx response.

Mod_fcgid, from what I know still assumes that every process it spawns can handle only one request at a time and doesn't pipeline requests. That, of course, doesn't work well with an php+apc setup, where fastcgi/fcgid spawns one subprocess, which in turn has its own children.

I don't really understand how php-fpm fits into the whole; after all, it still communicates with Apache using mod_fastcgi or mod_fcgid, doesn't it? Besides, I'd honestly prefer something that works without having to compile and maintain own versions of software, be it fpm-patched php or a non-ancient nginx (does its fastcgi module handle that situation better?).

Any hints?

This may or may not apply in your case, but I start my fcgi handlers separately from my web server. All the web server knows is an IP address (127.0.0.1) and a port number; restarting or reloading the web server has no effect on it.

Well, I'm only "almost" sure of that... but I think that just like it kills spawned subprocesses, mod_fastcgi cuts the connection to the external handler as soon as it gets the USR1. So in that case, while the scripts could execute, they have no way to send the data back.

Fcgid apparently doesn't support connecting to separate handler it did not spawn at all.

Bummer. Figures Apache would come up with some way to ruin that, too