From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggsout.gnu.org ([209.51.188.92]:56402 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gfmVe-0003gp-Cc for guix-patches@gnu.org; Sat, 05 Jan 2019 09:01:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gfmVa-0007W8-Cz for guix-patches@gnu.org; Sat, 05 Jan 2019 09:01:06 -0500 Received: from debbugsout.gnu.org ([209.51.188.43]:37038) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gfmVa-0007W2-8f for guix-patches@gnu.org; Sat, 05 Jan 2019 09:01:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gfmVa-0005Zj-1o for guix-patches@gnu.org; Sat, 05 Jan 2019 09:01:02 -0500 Subject: [bug#33508] [PATCH] gnu: Add ability to restart services on system reconfigure Resent-Message-ID: From: Ludovic =?UTF-8?Q?Court=C3=A8s?= References: <87efb8m5gy.fsf@zancanaro.id.au> <87lg4yws9a.fsf@gnu.org> <87h8eszkk5.fsf@zancanaro.id.au> Date: Sat, 05 Jan 2019 15:00:07 +0100 In-Reply-To: <87h8eszkk5.fsf@zancanaro.id.au> (Carlo Zancanaro's message of "Tue, 01 Jan 2019 22:25:30 +1100") Message-ID: <87tvin5hnc.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: Carlo Zancanaro Cc: 33508@debbugs.gnu.org Hi Carlo, Carlo Zancanaro skribis: > Sorry for not responding to this email for so long. I've been trying > to think through some of the issues around this, and I'm not confident > that I have thought through the issues well enough to actually decide > on a good course of action, beyond what I have already written. I'll > respond to a few specific things in your message, but I don't even > know what a good solution would look like, let alone how to build it. Sure, we can take more time to think through it. You earlier work in this area has already greatly improved the situation so I feel less pressure now. > I did some research into nginx, and it turns out that it is possible > to upgrade nginx with zero-downtime by running two daemons > simultaneously listening on the same port(s), then shutting down the > old daemon after the new one has successfully started[1]. This allows > for an "uninterrupted" upgrade, but I'm not confident that I would be > able to implement it within our current framework. Nginx does all this for us. Basically if you run =E2=80=9Cnginx -s restart= =E2=80=9D, IIRC, it automatically does the multi-process dance and you eventually end up with only upgraded nginx processes. However it relies on being able to read its new configuration file from the same location as before, which is something that doesn=E2=80=99t quite work in our setting, unless we make the file available at a fixed location like /etc/nginx.conf. Cl=C3=A9ment looked into this a while back but I cannot find the reference. Anyway I think we should probably special-case the =E2=80=98restart=E2=80= =99 action for those live-upgradable services. That doesn=E2=80=99t require any change in= the Shepherd. Thoughts? Ludo=E2=80=99.