Issue when sending USR2 too soon

Eric Wong normalperson at
Mon Jan 18 06:43:34 EST 2010

Iñaki Baz Castillo <ibc at> wrote:
> 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,
>                   ignored"
>   end
> 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.

On systems with RubyGems, the executable is always an automatically
generated wrapper script that does "require 'rubygems'" first.

> > 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'll look into what the consequences of writing the pid file after
signal handlers are setup later this week.

Unfortunately pid files are inherently racy for the USR2 case.  Perhaps
your script can check the ctime of the pid file...

Eric Wong

More information about the mongrel-unicorn mailing list