"Yeung, Jeffrey" <[email protected]> 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 - [email protected]
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
