Issue when sending USR2 too soon

Iñaki Baz Castillo ibc at
Mon Jan 18 06:25:28 EST 2010

El Lunes, 18 de Enero de 2010, Eric Wong escribió:
> Iñaki Baz Castillo <ibc at> 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:

  trap("USR2") do
    $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>

More information about the mongrel-unicorn mailing list