Re: What does it mean for the unicorn process to be bound to a terminal?

From: Rodrigo Rosenfeld Rosas <rr.rosas@gmail.com>
To: Eric Wong <normalperson@yhbt.net>
Cc: unicorn list <mongrel-unicorn@rubyforge.org>
Subject: Re: What does it mean for the unicorn process to be bound to a terminal?
Date: Tue, 26 Nov 2013 16:35:00 -0200	[thread overview]
Message-ID: <5294E9D4.5030608@gmail.com> (raw)
In-Reply-To: <20131126180400.GA15932@dcvr.yhbt.net>

Em 26-11-2013 16:04, Eric Wong escreveu:
> Rodrigo Rosenfeld Rosas <rr.rosas@gmail.com> 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 - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying