Hi, I followed the procedure to replace a running unicorn. Works fine, except for one thing: after I decide to back out, ie I send a HUP to the old master followed by a QUIT to the new master, then: 1. the new master does die, and the old master does work again 2. the "old" master keeps running with a process name of "master (old)" 3. the "old" master keeps running with a pid file named unicorn.pid.oldbin Because the file is now named unicorn.pid.oldbin a later attempt to deploy using scripts is made rather difficult as they assume a pid file named unicorn.pid. How could I get unicorn to rename the pid file back to unicorn.pid ? I see some code in method +reap_all_workers+ that suggests it would rename the pid file back to its original, but for some reason it doesn''t for me. Am I missing a step? PS. Using unicorn 1.1.1. Cheers, Lawrence
Lawrence Pit <lawrence.pit at gmail.com> wrote:> Hi, > > I followed the procedure to replace a running unicorn. Works fine, > except for one thing: after I decide to back out, ie I send a HUP to the > old master followed by a QUIT to the new master, then: > > 1. the new master does die, and the old master does work again > > 2. the "old" master keeps running with a process name of "master (old)" > > 3. the "old" master keeps running with a pid file named unicorn.pid.oldbin > > Because the file is now named unicorn.pid.oldbin a later attempt to > deploy using scripts is made rather difficult as they assume a pid file > named unicorn.pid. > > How could I get unicorn to rename the pid file back to unicorn.pid ? I > see some code in method +reap_all_workers+ that suggests it would rename > the pid file back to its original, but for some reason it doesn''t for > me. Am I missing a step?Hi Lawrence, Are you using a config file to specify pid or --pid from the command-line? The config file should be more reliable. I''ll take a deeper look at it in a bit. -- Eric Wong
> > How could I get unicorn to rename the pid file back to unicorn.pid ? I > > see some code in method +reap_all_workers+ that suggests it would rename > > the pid file back to its original, but for some reason it doesn''t for > > me. Am I missing a step? > > Hi Lawrence, > > Are you using a config file to specify pid or --pid from the > command-line? The config file should be more reliable. I''ll take a > deeper look at it in a bit. >Hi Eric, I''m using both. I have an /etc/init.d/unicorn script which is somewhat like your examples/init.sh (using start-stop-daemon instead of kill though) and a config file that is like your examples/unicorn_conf.rb (comments left untouched). Cheers, Lawrence
> Are you using a config file to specify pid or --pid from the > command-line? The config file should be more reliable. I''ll take a > deeper look at it in a bit. >fwiw, this is the /etc/init.d/unicorn script I''m using so far: http://gist.github.com/473547 Perhaps it''s of use to others as well. Background: the main feature I''m looking for is to deploy code using /etc/init.d/unicorn upgrade. Then a dozen (full stack) checks are executed which must all pass before the app is considered to be up. Depending on the outcome of those checks an /etc/init.d/unicorn commit or rollback follows. Cheers, Lawrence
Lawrence Pit <lawrence.pit at gmail.com> wrote:> Hi, > > I followed the procedure to replace a running unicorn. Works fine, > except for one thing: after I decide to back out, ie I send a HUP to the > old master followed by a QUIT to the new master, then:Ah, ok. I can reproduce it. The problem is the HUP by the old master tries to reset the pid file to the non-"oldbin" version which the new master is still holding on to. You could QUIT the new master first and then HUP, but this is _far_ from ideal because it leaves you with a window without running workers (and also it contradicts our documentation). It''s also difficult to avoid race conditions this way. I''m looking for a better way to go about this, pid files are nasty :x -- Eric Wong