zero down time on unicorn restart

[lidaobing]

• user can customize the sleep time after USR2 signal
• add set -x for verbose information on deploy

[sosedoff]

Tested? All good?

[lidaobing]

tested on my deploy process, no problem

[DavidAllison]

@sosedoff Hi Dan - any chance we could get this merged in, and perhaps some of the other issues related to it reviewed? I am happy to help analyze and debug (it seems that currently there is a conflict with the way the unicorn restart task works within capistrano-unicorn and the way most users are writing their unicorn.rb file's before and after_fork blocks).

[sfsekaran]

Any idea why?

[astropanic]

because

set -x

sends output to STDERR and you see the "err" indicator in Capistrano in red.

This is not a error in itself (the task works properly) but will for sure bring confusion to people.
Marking something red with errors, while working correctly brings a lot of confusion.
I would suggest use STDERR for what it was designed for.
Sending everything to STDERR for debugging purpose is bad practice.
You can affect the destination for set -x, but only from Bash version >= 4.1 via the BASH_XTRACEFD, but please don't do it...

[sfsekaran]

I see. Yeah, I wouldn't want everything going through STDERR either. Please send over a pull request removing that. Unless anyone else has a good reason not to, I'm going to merge it straightaway.

On Monday, April 29, 2013 at 11:00 AM, Wojciech Pietrzak wrote:

because
set -x
sends output to STDERR and you see the "err" indicator in Capistrano in red.
This is not a error in itself (the task works properly) but will for sure bring confusion to people.
Marking something red with errors, while working correctly brings a lot of confusion.
I would suggest use STDERR for what it was designed for.
Sending everything to STDERR for debugging purpose is bad practice.
You can affect the destination for set -x, but only from Bash version >= 4.1 via the BASH_XTRACEFD, but please don't do it...

—
Reply to this email directly or view it on GitHub (#41 (comment)).

[astropanic]

Here you go #54

[sfsekaran]

@astropanic ⚡

[nextofsearch]

Does this gem support zero-downtime deployment yet?
It seems like it is not working.

[sfsekaran]

@nextofsearch My knowledge of zero-downtime deployment options:

• unicorn:restart: 👎 This can sort of support it with a configurable timeout, which can be very finicky.
• unicorn:reload: ❓ I don't use this one currently. Can anyone testify to its zero-downtime support?
• unicorn:duplicate: 👍 If you install the Unicorn before_fork hook, then yes! See: unicorn:restart sends QUIT to old master before new master's workers are up #40 (comment)

[nextofsearch]

@sfsekaran thanks a lot!!