Unicorn preload_app and upstart

Unicorn preload_app and upstart

[Rob Greenwood]

Hi, 

I was wondering if anyone has managed to get the preload_app and SIGUSR2
combination working well with upstart?

My issue currently is that when I perform a SIGUSR2 against the master,
check everything's working and close off the old master, upstart then
attempts to restart it because the original PID/binary are no longer
running.

What is the correct way of handling this? In my opinion, should unicorn
not always be using the same master process and just spawning additional
children/cycling them? Else the above functionality will never work with
upstart, which will be replacing init.

Thanks,
Rob



Rob Greenwood

You'll love cloud hosting with Serverlove!
Find out more at http://www.serverlove.com
 
Phone us 0161 232 0125 | Email us rob.greenwood@melbourne.co.uk
Visit us http://www.melbourne.co.uk | Follow us http://twitter.com/melbournehost
 
Office Address | Turing House, Archway, Manchester, M15 5RL 
 
Melbourne Server Hosting Ltd
Registered in England and Wales, Company Number 4091836.
 
Please don’t print this email unless necessary.  
Our Environmental and Ethical Policy can be found at:
http://www.melbourne.co.uk/env 

_______________________________________________
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

Unicorn preload_app and upstart

[Rob Greenwood]

Hi,

I was wondering if anyone has managed to get the preload_app and SIGUSR2
combination working well with upstart?

My issue currently is that when I perform a SIGUSR2 against the master,
check everything's working and close off the old master, upstart then
attempts to restart it because the original PID/binary are no longer
running.

What is the correct way of handling this? In my opinion, should unicorn
not always be using the same master process and just spawning additional
children/cycling them? Else the above functionality will never work with
upstart, which will be replacing init.

Thanks,
Rob



Rob Greenwood

You'll love cloud hosting with Serverlove!
Find out more at http://www.serverlove.com
 
Phone us 0161 232 0125 | Email us rob.greenwood@melbourne.co.uk
Visit us http://www.melbourne.co.uk | Follow us http://twitter.com/melbournehost
 
Office Address | Turing House, Archway, Manchester, M15 5RL 
 
Melbourne Server Hosting Ltd
Registered in England and Wales, Company Number 4091836.
 
Please don’t print this email unless necessary.  
Our Environmental and Ethical Policy can be found at:
http://www.melbourne.co.uk/env 

_______________________________________________
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

Re: Unicorn preload_app and upstart

[Eric Wong]

Rob Greenwood <Rob.Greenwood@melbourne.co.uk> wrote:
> Hi,
> 
> I was wondering if anyone has managed to get the preload_app and SIGUSR2
> combination working well with upstart?
> 
> My issue currently is that when I perform a SIGUSR2 against the master,
> check everything's working and close off the old master, upstart then
> attempts to restart it because the original PID/binary are no longer
> running.

I guess upstart is similar to daemontools in this respect?

I posted a potentially working script to wrap unicorn and preserve
the same pid with daemon tools in this thread:

http://thread.gmane.org/gmane.comp.lang.ruby.unicorn.general/917
http://mid.gmane.org/20110425183458.GA5826%40dcvr.yhbt.net

> What is the correct way of handling this? In my opinion, should unicorn
> not always be using the same master process and just spawning additional
> children/cycling them? Else the above functionality will never work with
> upstart, which will be replacing init.

USR2 needs to be able to load a new Ruby executable and the only way is
to replace the master.  And for "preload_app true" to work, Unicorn
itself has to manage processes.


If you teach upstart/daemontools to bind listeners, you can have them
export a comma-separated list of listener file descriptors in the
UNICORN_FD environment (e.g. UNICORN_FD=3,4) and use QUIT + restart in
upstart/daemontools and avoid using USR2 entirely.

Unicorn itself still has to be given the listen directives in its own
config file otherwise it'll close them (because it assumes the user
no longer wants them on upgrade) and also to change socket options
if there are any.

You'll still get transparent restarts because the listeners will be
owned by daemontools/upstart and the queued listeners will be
held there.


Unicorn doesn't need to be used with upstart/daemontools, the master
process should be just as robust as them.  The only possible issue is
during HUP/USR2 where a bad upgrade has an (unlikely) chance of killing
the master, but if you're issuing HUP/USR2, you're paying attention to
the machine anyways.

If you want auto-startup, consider having a startup task in the @reboot
line in a crontab.  You can even put it in a regular user's crontab to
avoid needing to switch users.


Everything about the Unicorn process model with upstart/daemontools
applies to nginx upgrades, too.

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