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:

  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.

 
> 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.
 

Thanks.

-- 
Iñaki Baz Castillo <ibc at aliax.net>


More information about the mongrel-unicorn mailing list