Em 26-11-2013 16:04, Eric Wong escreveu:
Rodrigo Rosenfeld Rosas <[email protected]> wrote:
For a long time I struggle to understand this part:
http://unicorn.bogomips.org/SIGNALS.html
"3. You can now send WINCH to the old master process so only the new
workers serve requests. If your unicorn process is bound to an
interactive terminal, you can skip this step."
I asked a teammate and he didn't understand this part either, so
maybe it's confusing for other people too.
Would you mind to clarify what you mean by that?
It means actions on the terminal which started unicorn won't affect it.
So if the user hits Ctrl-C from the terminal, unicorn will not receive
SIGINT. Likewise for Ctrl-\ and SIGINT, and if a user resizes his
terminal (common with xterm and friends), there's no SIGWINCH.
setsid(2) is the syscall used to detach from a controlling terminal
(among other things). Maybe there's documentation elsewhere to the
setsid(2) which explains this part more, but neither the POSIX nor Linux
manpage for that distributed by Debian (wheezy) really explain this.
I see. If I understood correctly this only happens in foreground mode,
so something like that would help me to understand the sentence:
"...If your unicorn process is bound to an interactive terminal (running in the
foreground), you can skip this step."
Also, a section with suggestions on how to properly automate a
deployment with no downtime would be helpful.
What I see is that most recipes, like the ones I've seen for
Capistrano for example, will simply send a QUIT after USR2 to the
old master without actually checking if the deploy was successful
and won't use the WINCH and HUP signals to deal with health
checking...
Patches welcome.
I'd provide one if I could figure out some good way to automate this.
Currently I perform all steps manually in production for zero downtime
and only manage the other environments with Capistrano, except when I
have a programmed downtime window for production.
I haven't deployed an app entirely with Capistrano in
years nor do I use any common/widely-known deployment system. I usually
just end using something like the init script in examples/init.sh
I believe it would help the documentation if you added a link to init.sh
in the SIGNALS page:
http://bogomips.org/unicorn.git/tree/examples/init.sh
Anyway, even that script won't take care of making sure that the reload
action will rollback in case of an unsuccessful deploy.
I realize it's not easy to detect if the deploy was successful and that
it's very application dependent, but some generic procedures would be
helpful for a basic Rails application. Unfortunately I don't know what
would be a good strategy, that's why I asked :P
Thank you for explaining the interactive terminal binding question :)
Best,
Rodrigo.
_______________________________________________
Unicorn mailing list - [email protected]
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
