rework master-to-worker signaling to use a pipe
commit6f6e4115b4bb03e5e7c55def91527799190566f2
authorEric Wong <e@80x24.org>
Mon, 9 Dec 2013 09:20:39 +0000 (9 09:20 +0000)
committerEric Wong <normalperson@yhbt.net>
Mon, 9 Dec 2013 09:41:57 +0000 (9 09:41 +0000)
tree21558c2fb2e24b9b00c4f5d06c488b43a0073502
parentfa17da92aa4e76d5fd63cb9b74d6884d611ec899
rework master-to-worker signaling to use a pipe

Signaling using normal kill(2) is preserved, but the master now
prefers to signal workers using a pipe rather than kill(2).
Non-graceful signals (:TERM/:KILL) are still sent using kill(2),
as they ask for immediate shutdown.

This change is necessary to avoid triggering the ubf (unblocking
function) for rb_thread_call_without_gvl (and similar) functions
extensions.  Most notably, this fixes compatibility with newer
versions of the 'pg' gem which will cancel a running DB query if
signaled[1].

This also has the nice side-effect of allowing a premature
master death (assuming preload_app didn't cause the master to
spawn off rogue child daemons).

Note: users should also refrain from using "killall" if using the
'pg' gem or something like it.

Unfortunately, this increases FD usage in the master as the writable
end of the pipe is preserved in the master.  This limit the number
of worker processes the master may run to the open file limit of the
master process.  Increasing the open file limit of the master
process may be needed.  However, the FD use on the workers is
reduced by one as the internal self-pipe is no longer used.  Thus,
overall pipe allocation for the kernel remains unchanged.

[1] - pg is correct to cancel a query, as it cannot know if
      the signal was for a) graceful unicorn shutdown or
      b) oh-noes-I-started-a-bad-query-ABORT-ABORT-ABORT!!
SIGNALS
lib/unicorn.rb
lib/unicorn/http_server.rb
lib/unicorn/worker.rb