Issue when sending USR2 too soon
Iñaki Baz Castillo
ibc at aliax.net
Mon Jan 18 06:48:49 EST 2010
El Lunes, 18 de Enero de 2010, Eric Wong escribió:
> On systems with RubyGems, the executable is always an automatically
> generated wrapper script that does "require 'rubygems'" first.
True, but I use Ruby 1.9 which doesn't require using "rubygems". However it's
of course true that the binary does a "gem_load_bin('unicorn'..)" and so.
But in my case, for now, I use directly the *real* executable rather than the
executable that Gem puts in /usr/bin or /usr/local/bin.
> > > 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.
Hum, yes, that sound good.
> Unfortunately pid files are inherently racy for the USR2 case. Perhaps
> your script can check the ctime of the pid file...
Good suggestion :)
Iñaki Baz Castillo <ibc at aliax.net>
More information about the mongrel-unicorn