Re: Unicorn + RUnit Rails Not Killing Old Master

[Graham Christensen <graham@grahamc.com>]

On 2013-05-20 17:28:51 +0000, Eric Wong said:

> Graham Christensen <graham@grahamc.com> wrote:
>> I'm deploying Unicorn on a Rails application with RUnit. Technically
>> I'm using Chef's deployment tools, if any of you are familiar with
>> it (https://github.com/opscode-cookbooks/application_ruby) but to be
>> clear they aren't doing anything magical, so this is purely an issue
>> with RUnit and Unicorn.
>> 
>> The TL;DR of the following post, which has lots of pastes (linking
>> to pastebins for easier reading:) when I run /etc/init.d/myzippykid
>> restart, the old unicorn master fails to die, causing the new master
>> to be stuck in a loop waiting to own port 8080. The new master never
>> takes over, as the old master never dies. When I manually kill the
>> master, the new one takes over just fine.
>> 
>> What am I missing in my restart process to make the old master exit?
> 
> It seems you're missing /etc/init.d/myzippykid in your pastes.

The /etc/init.d/myzippykid is symlinked to /usr/bin/sv which is a 
binary provided by runit.

> 
> Are you sending SIGQUIT (or SIGTERM) to the old unicorn master?
> If you have old workers servicing requests, the old master will wait
> until all the old workers are done.

This is an interesting question. runit appear to be capturing the PID 
of my bundle_wrapper.sh instead of the spawned unicorn process. Since 
this isn't interactive, it probably isn't forwarding the signals to 
Unicorn. After replacing the `bundle $@` with `exec bundle $@`, and 
therefore replacing the process with the unicorn command, it all works 
as intended.

I suppose all it took was that question to jog my memory.

I appreciate your assistance! Here is the complete bundle_wrapper.sh 
wthich implements everything as intended:
#!/bin/bash

source /etc/profile.d/rbenv.sh

exec bundle $@

> 
> Since your timeout is 60s, everything (workers and master) should exit
> around that time period if you have stalled/long-running requests,
> though.

Since Unicorn doen't seem to be receiving the signals, this would 
explain why the timeout never was hit, and nothing ever exited.

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

Thank you a lot!

Graham Christensen


_______________________________________________
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