Issue when sending USR2 too soon
Iñaki Baz Castillo
ibc at aliax.net
Mon Jan 18 06:25:28 EST 2010
El Lunes, 18 de Enero de 2010, Eric Wong escribió:
> Iñaki Baz Castillo <ibc at aliax.net> wrote:
> > El Domingo, 17 de Enero de 2010, Iñaki Baz Castillo escribió:
> > > What about if Unicorn very quicky prepares the trap for USR2 so in case
> > > it receives it soon when starting it ignores it (and logs some
> > > warning)? Does it make sense?
> > Adding the following on the top of bin/unicorn solves the problem:
> > # Ignore USR2 (instead of terminating script) in case it arrives too
> > soon. trap("USR2") do
> > $stderr.puts "WARN: USR2 signal (reload action) received too soon,
> > ignored" end
> No it doesn't, it just reduces the window where signals aren't setup.
> On systems where Unicorn is installed as a RubyGem, that window of time
> may be much bigger.
But note that I've added:
$stderr.puts "WARN: USR2 signal (reload action) received too soon,
at the beginning of the executable, so the time window is really reduced. Also
note that in my modified version of the executable I load many other gems and
them make the unicorn loading slower, increasing the time window.
> Is the issue with a script reading the pid file and sending the signal
> because it exists?
I've done a init script to start/stop/reload/log-rotate Unicorn. The action
"log-rotate" takes the PID from the pid file and sends a USR1 (this call is
made by logrotate). The action "reload" sends a USR2 and later a TERM
(depending on if the PID has changed or not).
I just want to avoid that, in case a user invokes "reload" twice too fast,
Unicorn receives USR2 before preparing it so it dies. With my "hack" is more
difficult such possibility to occur.
Iñaki Baz Castillo <ibc at aliax.net>
More information about the mongrel-unicorn