On 07/05/2013, at 4:59 PM, Ben Hoskings <[email protected]> wrote:

> Chris --
> 
> That's what I mean; USR2 restarts involve the original process disappearing 
> completely, but that is usually treated as an error by upstart and the like. 
> It's not good enough to exit the unicorn and have the monitoring restart it, 
> because that causes downtime. (I might be misunderstanding you there.)
> 
> I don't monitor unicorn with a separate tool; I treat the unicorn master as 
> monitoring for the workers. I use upstart to monitor things like delayed_job, 
> though, and restart them on deploy (the deploy process just sends them 
> SIGQUIT).

I suspect you should be using SIGTERM rather than SIGQUIT to stop delayed_job.

Unicorn handles SIGQUIT in a non-standard (nice) way, but delayed_job doesn't 
seem to:
https://github.com/collectiveidea/delayed_job/blob/master/lib/delayed/worker.rb#L134-144
It traps SIGTERM (normal clean shutdown) and SIGINT (ctrl-c clean shutdown).

Aside: if you're using Unicorn, you should read 
http://unicorn.bogomips.org/SIGNALS.html many times.

TL;DR for the following: SIGQUIT is a user-requested crash, process shouldn't 
clean up after itself.


> The SIGQUIT signal is sent to a process by its controlling terminal when the 
> user requests that the process perform a core dump.
— http://en.wikipedia.org/wiki/Unix_signal#POSIX_signals

> The SIGQUIT signal is similar to SIGINT, except that it's controlled by a 
> different key—the QUIT character, usually C-\—and produces a core dump when 
> it terminates the process, just like a program error signal. You can think of 
> this as a program error condition “detected” by the user.
> 
> See Program Error Signals, for information about core dumps. See Special 
> Characters, for information about terminal driver support.
> 
> Certain kinds of cleanups are best omitted in handling SIGQUIT. For example, 
> if the program creates temporary files, it should handle the other 
> termination requests by deleting the temporary files. But it is better for 
> SIGQUIT not to delete them, so that the user can examine them in conjunction 
> with the core dump.
— http://www.gnu.org/software/libc/manual/html_node/Termination-Signals.html


— Paul

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
or Rails Oceania" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/rails-oceania?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to