unicorn Ruby/Rack server user+dev discussion/patches/pulls/bugs/help
 help / color / mirror / code / Atom feed
From: Eric Wong <normalperson@yhbt.net>
To: unicorn list <mongrel-unicorn@rubyforge.org>
Subject: Re: Issue when sending USR2 too soon
Date: Mon, 18 Jan 2010 11:43:34 +0000	[thread overview]
Message-ID: <20100118114334.GC4625@dcvr.yhbt.net> (raw)
In-Reply-To: <201001181225.28388.ibc@aliax.net>

Iñaki Baz Castillo <ibc@aliax.net> wrote:
> El Lunes, 18 de Enero de 2010, Eric Wong escribió:
> > Iñaki Baz Castillo <ibc@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.

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


  reply	other threads:[~2010-01-18 11:43 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-17  1:44 Issue when sending USR2 too soon Iñaki Baz Castillo
2010-01-17  1:52 ` Iñaki Baz Castillo
2010-01-17  1:59   ` Iñaki Baz Castillo
2010-01-18 11:04     ` Eric Wong
2010-01-18 11:25       ` Iñaki Baz Castillo
2010-01-18 11:43         ` Eric Wong [this message]
2010-01-18 11:48           ` Iñaki Baz Castillo
2010-01-20  2:38           ` [PATCH] initialize signal handlers before writing pid file Eric Wong
2010-01-20  8:45             ` Iñaki Baz Castillo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://yhbt.net/unicorn/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100118114334.GC4625@dcvr.yhbt.net \
    --to=normalperson@yhbt.net \
    --cc=mongrel-unicorn@rubyforge.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://yhbt.net/unicorn.git/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).