Feature #2177


USR1 kill signal special case for fcgi

Added by kapouer over 12 years ago. Updated about 12 years ago.

Target version:


Multiwatch main purpose is to be used with spawn-fcgi;
fastcgi expects USR1 signal to quit its loop nicely.
The trouble is i must send two signals to kill it :
the first one USR1 to kill its forked fcgi childs, and a second
one TERM or KILL to stop multiwatch itself, or else multiwatch
respawns killed childs.
(sending directly TERM or KILL is not "nice" to the spawned fcgi childs).

Otherwise i set up runit + spawn-fcgi + multiwatch + rails and
it's working quite nicely, thank you.

Actions #1

Updated by stbuehler over 12 years ago

Hi, i guess i don't have to mail you the project site now :)

I'd somehow like to have this configurable; so you could for example use USR2 to cycle log files and USR1 to kill the app after the current request.
And i think i could add an option for a "nice terminate signal", so on the first terminating signal multiwatch will send the "nice signal" instead of forwarding the original (i.e. kill multiwatch with SIGINT, multiwatch kills children with SIGUSR1).

The defaults would be SIGUSR1 for the term signal, and multiwatch terminating on SIGUSR1 too.

Actions #2

Updated by kapouer over 12 years ago

multiwatch receives signal : TERM KILL USR1 USR2
spawned process receives : USR1 KILL USR1 USR2

-> fastcgi process is terminated by USR1 instead of TERM, so that's the correct intent.
because runit's sv "sv stop xxx" sends TERM,
and i bet others like daemontools behave the same.

Maybe all that's needed is a simple --fcgi switch to indicate multiwatch should send USR1 on TERM ?


Actions #3

Updated by stbuehler about 12 years ago

  • Status changed from New to Fixed
  • Target version set to 1.0.0
  • % Done changed from 0 to 100

Fixed in 80d85493

Actions #4

Updated by kapouer about 12 years ago

Thanks !


Also available in: Atom