On Tue, Aug 2, 2011 at 17:53, Eric Wong <[email protected]> wrote: > James Cox <[email protected]> wrote: >> Hey, >> >> So here are some tasks for managing unicorn: >> >> https://gist.github.com/1121076 > > Can we ignore the :restart task? It's a bit fragile since it doesn't > wait for the old process to die (SIGTERM means > kill-as-quickly-as-possible, but given a loaded system it can still take > some time).
We mostly restart (what surprise). What pattern works best here for that? (speed of deploy is important, but definitely assume a long boot time) > >> I've found that it's very unreliable for quitting / terminating >> unicorn and restarting with new code. When doing rapid deployments >> particularly, i've found that i have to go in and kill -9 the master >> process, and start again. > > If you SIGQUIT/SIGTERM before the app is loaded, the signal could > be ignored. This behavior should probably change... > >> any thoughts on why it seems ineffective? >> >> Thanks. > > Which version of Unicorn are you using? I recall some minor tweaks > to avoid/minimize race conditions over the years so maybe some > are fixed. > gem 'unicorn' - so whatever seems up to date. My lock says 4.0.1 >> PS: here's the unicorn config: >> >> https://gist.github.com/0dd07c5ad00c56d161c7 > > Avoid the top piece of the before_fork hook to TTOU workers, it's > needlessly complex for most deployments unless you're really > memory-constrained. > So what should that look like? all but that nr-workers stuff? can i just remove the before fork? and what would you say is a super good unicorn config to start from? thanks! james _______________________________________________ Unicorn mailing list - [email protected] http://rubyforge.org/mailman/listinfo/mongrel-unicorn Do not quote signatures (like this one) or top post when replying
