mongrel unicorn - Nov 2013 - What does it mean for the unicorn process to be bound to a terminal?

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?

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

Cheers,
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

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

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

On Tue, Nov 26, 2013 at 10:35 AM, Rodrigo Rosenfeld Rosas
<rr.rosas@gmail.com> wrote:
> 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.
Here''s what we do (this is in unicorn.rb).  We send the master a
SIGUSR2 via our init script, which starts the process.

http://pastebin.com/02y0y34q

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

Rodrigo Rosenfeld Rosas <rr.rosas@gmail.com>
wrote:
> 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."
I used "not daemonized", since it''s possible for a background
process
to have a controlling terminal:

     unicorn ... & # runs background, still attached to terminal
     fg # foreground again

Pushed as fa17da92aa4e76d5fd63cb9b74d6884d611ec899
(also added a link to the init.sh example)
---------------------------8<----------------------------
Subject: [PATCH] doc: clarify SIGNALS and reference init example

"interactive terminal" needed clarification.

While we''re at it, link to the init.sh example since it may
be shared with nginx.

Reported-by: Rodrigo Rosenfeld Rosas
ref: <5294E9D4.5030608@gmail.com>
---
 SIGNALS | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/SIGNALS b/SIGNALS
index 8851775..48c651e 100644
--- a/SIGNALS
+++ b/SIGNALS
@@ -7,6 +7,9 @@ signal handling matches the behavior of
{nginx}[http://nginx.net/] so it
 should be possible to easily share process management scripts between
 Unicorn and nginx.
 
+One example init script is distributed with unicorn:
+http://unicorn.bogomips.org/examples/init.sh
+
 === Master Process
 
 * HUP - reloads config file and gracefully restart all workers.
@@ -101,8 +104,8 @@ The procedure is exactly like that of nginx:
 
 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.  Step 5 will be more difficult but
-   you can also skip it if your process is not daemonized.
+   terminal (not daemonized), you can skip this step.  Step 5 will be more
+   difficult but you can also skip it if your process is not daemonized.
 
 4. You should now ensure that everything is running correctly with the
    new workers as the old workers die off.
---------------------------8<----------------------------
> 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
Right.  Different apps require different validation, especially
those intended for GUI web browsers.
> Thank you for explaining the interactive terminal binding question :)
No problem!
_______________________________________________
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

Oy,

On Tue, Nov 26, 2013 at 8:14 PM, Michael Fischer <mfischer@zendesk.com>
wrote:
> On Tue, Nov 26, 2013 at 10:35 AM, Rodrigo Rosenfeld Rosas
> <rr.rosas@gmail.com> wrote:
>
>> 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.
>
At Fotopedia, we have a special piece of code to automate the 0
downtime restart of Unicorns. It performs quite well in production for
us. A complete article about that can be found at:

http://fotopedia-code.tumblr.com/post/64393785879/life-and-death-of-unicorns

Let me know off-list if you have any question or remark about that
piece of software...

Cheers,
-- 
Pierre Baillet <oct@fotopedia.com>
Server Shepherd @ http://www.fotopedia.com/
_______________________________________________
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