Re: Issue with unicorn not starting via bluepill?

[ghazel@gmail.com]

On Fri, Mar 19, 2010 at 1:57 AM, Eric Wong <normalperson@yhbt.net> wrote:
> Eric Wong <normalperson@yhbt.net> wrote:
>> James Cox <james@imaj.es> wrote:
>> > trying to start my unicorn via bluepill, and running into this :
>
>> > master failed to start, check stderr log for details

For reference, this is not the error I get. I'm running "upgrade",
which is sig USR2, and getting two masters (one marked (old)) and two
sets of children.

> Both of you:
>
> Was there anything useful in stderr_path?  The daemomized
> process can never output to the terminal, so it had to
> log somewhere... There's also strace, but looking at the
> Unicorn code I haven't been able to find much (I'm very
> sleep deprived right now, though).

The only thing out of the ordinary I see in the log is:

retrying in 5 seconds (infinite tries left)
adding listener failed addr=127.0.0.1:9011 (in use)

as each of the admin interface TCP socket listeners fails on the
workers because there are still the old workers running.


> @Greg: I got through to /v6lUsuzD finally, can you put some
> debug statements around your before_fork hook and print out
> the pid path name and whether it exists or not?

server.config[:pid]: "/data/myapp/shared/pids/unicorn.pid"
exists?: true
old_pid: "/data/myapp/shared/pids/unicorn.pid.oldbin"
exists?: true
server.pid: "/data/myapp/shared/pids/unicorn.pid"
old_pid: "/data/myapp/shared/pids/unicorn.pid.oldbin"
server.pid != old_pid: true

It looks like trying to send a SIGQUIT to the old master does nothing.
Sending it a SIGTTOU does seem to reduce the number of workers, but
even when there are 0 left it does not die after a SIGQUIT.

Looking at the Unicorn source and my config:
http://codepad.org/v6lUsuzD I'm not sure what from the 0.96.1 was
supposed to be sending SIGTTOU. There are not any being sent, from
what I can tell. In the 0.96.1 to 0.96.1 upgrade case, I see the old
master get a bunch of SIGQUITs and reap its own children. In the
0.99.0 case I see no SIGQUITs arrive at the old master... In fact,
just running 0.99.0 and trying to send it a SIGQUIT does nothing.
SIGINT works fine, so do TTOU, TTIN, USR1 etc. I added a log message
to the trap handler registered in trap_deferred, and it is never being
called...

Turns out, I had query_trace installed, and the change in to trap
handler initialization registered it before query_trace initialized.
Later, query_trace registered a QUIT handler and did not call any
existing handlers. I have since uninstalled that broken junk.

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