Hi,
Currently trying to sort out: https://bugzilla.redhat.com/show_bug.cgi?id=821926
Following an update to the nginx package, the command below would allow the server to switch to the new binary with zero-downtime (new process created, old process gracefully phased out):
/etc/init.d/nginx upgrade
This has disappeared following migration to systemd, so my intention is to include an nginx-upgrade shell script to replace this functionality.
My question is, where should this shell script go? In /usr/bin/nginx-upgrade?
(As an aside, the other approach is to *automatically* do a zero-downtime upgrade in %post. This is the simplest solution and I think Debian do an automatic zero-downtime upgrade for their nginx package. I was entertaining this idea earlier but now feel it's safer and more in line with user expectations to require manual intervention. In most cases, currently running services are not affected by system updates without manually restarting the service.)
Kind regards, Jamie
On 05/16/2012 12:21 AM, Jamie Nguyen wrote:
/etc/init.d/nginx upgrade
This has disappeared following migration to systemd, so my intention is to include an nginx-upgrade shell script to replace this functionality.
My question is, where should this shell script go? In /usr/bin/nginx-upgrade?
Yes, this looks like a good choice to me.
Then immediately a question comes to mind: Shouldn't the script be pushed upstream, rather than being a Fedora-specific addition?
Michal
On Wed, May 16, 2012 at 01:19:20AM +0200, Michal Schmidt wrote:
On 05/16/2012 12:21 AM, Jamie Nguyen wrote:
/etc/init.d/nginx upgrade
This has disappeared following migration to systemd, so my intention is to include an nginx-upgrade shell script to replace this functionality.
My question is, where should this shell script go? In /usr/bin/nginx-upgrade?
Yes, this looks like a good choice to me.
Then immediately a question comes to mind: Shouldn't the script be pushed upstream, rather than being a Fedora-specific addition?
Also, implementing socket-activation in nginx would make it upgradable without losing any connections.
On 16 May 2012 08:16, Tomasz Torcz tomek@pipebreaker.pl wrote:
On Wed, May 16, 2012 at 01:19:20AM +0200, Michal Schmidt wrote:
On 05/16/2012 12:21 AM, Jamie Nguyen wrote:
/etc/init.d/nginx upgrade
This has disappeared following migration to systemd, so my intention is to include an nginx-upgrade shell script to replace this functionality.
My question is, where should this shell script go? In /usr/bin/nginx-upgrade?
Yes, this looks like a good choice to me.
Then immediately a question comes to mind: Shouldn't the script be pushed upstream, rather than being a Fedora-specific addition?
Also, implementing socket-activation in nginx would make it upgradable without losing any connections.
Sorry, could you clarify? I don't see how that would help in this situation.
AFAIK, systemd socket activation is useful either for parallelization during system startup, or on-demand activation. The former doesn't help, and the latter is definitely not what we want for a web server.
Kind regards, Jamie
On Wed, May 16, 2012 at 06:10:08PM +0100, Jamie Nguyen wrote:
On 16 May 2012 08:16, Tomasz Torcz tomek@pipebreaker.pl wrote:
On Wed, May 16, 2012 at 01:19:20AM +0200, Michal Schmidt wrote:
On 05/16/2012 12:21 AM, Jamie Nguyen wrote:
/etc/init.d/nginx upgrade
This has disappeared following migration to systemd, so my intention is to include an nginx-upgrade shell script to replace this functionality.
My question is, where should this shell script go? In /usr/bin/nginx-upgrade?
Yes, this looks like a good choice to me.
Then immediately a question comes to mind: Shouldn't the script be pushed upstream, rather than being a Fedora-specific addition?
Also, implementing socket-activation in nginx would make it upgradable without losing any connections.
Sorry, could you clarify? I don't see how that would help in this situation.
AFAIK, systemd socket activation is useful either for parallelization during system startup, or on-demand activation. The former doesn't help, and the latter is definitely not what we want for a web server.
If the new request comes during nginx restart¹, it won't be lost. Socket is always opened by systemd and the connection will be buffered until new nginx is ready to server it.
¹ in time between old nginx closing its socket and new nginx creating new
On 16 May 2012 20:09, Tomasz Torcz tomek@pipebreaker.pl wrote:
On Wed, May 16, 2012 at 06:10:08PM +0100, Jamie Nguyen wrote:
On 16 May 2012 08:16, Tomasz Torcz tomek@pipebreaker.pl wrote:
Also, implementing socket-activation in nginx would make it upgradable without losing any connections.
Sorry, could you clarify? I don't see how that would help in this situation.
AFAIK, systemd socket activation is useful either for parallelization during system startup, or on-demand activation. The former doesn't help, and the latter is definitely not what we want for a web server.
If the new request comes during nginx restart¹, it won't be lost. Socket is always opened by systemd and the connection will be buffered until new nginx is ready to server it.
¹ in time between old nginx closing its socket and new nginx creating new
Will look into this. Thanks for clarifying!
Kind regards, Jamie
On 16 May 2012 00:19, Michal Schmidt mschmidt@redhat.com wrote:
On 05/16/2012 12:21 AM, Jamie Nguyen wrote:
/etc/init.d/nginx upgrade
This has disappeared following migration to systemd, so my intention is to include an nginx-upgrade shell script to replace this functionality.
My question is, where should this shell script go? In /usr/bin/nginx-upgrade?
Yes, this looks like a good choice to me.
Then immediately a question comes to mind: Shouldn't the script be pushed upstream, rather than being a Fedora-specific addition?
This script doesn't do anything new compared to our initscript, so upstream probably won't do much more than document it here: http://wiki.nginx.org/CommandLine#Upgrading_To_a_New_Binary_On_The_Fly
The simplest form of the script is literally just 2 commands (though I've implemented it in a slightly more calculated manner): /bin/systemctl kill --signal=USR2 nginx.service /bin/systemctl kill --signal=QUIT --kill-who=main nginx.service
Nonetheless, I have offered both our nginx.service file and the above script to be upstreamed, or at least documented in their wiki: http://mailman.nginx.org/pipermail/nginx-devel/2012-May/002228.html
Thanks for your advice.
Kind regards, Jamie