El Lunes, 18 de Enero de 2010, Eric Wong escribió:
> Iñaki Baz Castillo <i...@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 <i...@aliax.net>
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
