On Fri, Mar 19, 2010 at 1:57 AM, Eric Wong <[email protected]> wrote: > Eric Wong <[email protected]> wrote: >> James Cox <[email protected]> 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 - [email protected] http://rubyforge.org/mailman/listinfo/mongrel-unicorn Do not quote signatures (like this one) or top post when replying
