Re: Unicorn_rails ignores USR2 signal

[Eric Wong <normalperson@yhbt.net>]

"Yeung, Jeffrey" <Jeffrey.Yeung@polycom.com> wrote:
> Thanks Eric.  New strace capture as follows:
> 
>  $ sudo strace -f -e '!futex' -p 14255
>  Process 14255 attached with 12 threads - interrupt to quit

>From that, you have 5 worker processes?

For debugging this, it can cut down on noise to only use one worker
process, too.  You can check if SIGTTOU works, too :)

Also, can you reproduce this on a freshly-started master?  Or has
the master been running and handling other signals for a while?

The most common cause of USR2 failures is due to an executable or
library being moved/replaced/upgraded away (sometimes due to
Capistrano), but that should definitely get logged and doesn't seem to
be the case for you.

>  [pid 14322] restart_syscall(<... resuming interrupted call ...> <unfinished ...>
>  [pid 14271] restart_syscall(<... resuming interrupted call ...> <unfinished ...>
>  [pid 14267] accept(12,  <unfinished ...>
>  [pid 14264] restart_syscall(<... resuming interrupted call ...> <unfinished ...>
>  [pid 14255] select(6, [5], NULL, NULL, {42, 86504} <unfinished ...>
>  [pid 14322] <... restart_syscall resumed> ) = -1 ETIMEDOUT (Connection timed out)
>  [pid 14271] <... restart_syscall resumed> ) = -1 ETIMEDOUT (Connection timed out)
>  [pid 14264] <... restart_syscall resumed> ) = -1 ETIMEDOUT (Connection timed out)
>  [pid 14262] --- SIGUSR2 (User defined signal 2) @ 0 (0) ---
>  [pid 14262] rt_sigreturn(0x20)          = 202
> 
> The last two lines do not say much for the event.  :(

Anything more after that?  What happens when you send a previously
working signal (USR1, HUP) after sending a failed USR2 to that process?
_______________________________________________
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