Re: Issue when sending USR2 too soon

["Iñaki Baz Castillo" <ibc@aliax.net>]

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