Issue with unicorn not starting via bluepill?

ghazel at ghazel at
Wed May 26 04:31:13 EDT 2010

On Fri, Mar 19, 2010 at 1:57 AM, Eric Wong <normalperson at> wrote:
> Eric Wong <normalperson at> wrote:
>> James Cox <james at> 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= (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/"
exists?: true
old_pid: "/data/myapp/shared/pids/"
exists?: true "/data/myapp/shared/pids/"
old_pid: "/data/myapp/shared/pids/" != 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: 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

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.


More information about the mongrel-unicorn mailing list