From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55544) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gRNEk-00081B-Nc for guix-patches@gnu.org; Mon, 26 Nov 2018 15:12:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gRNEg-0002r0-Qj for guix-patches@gnu.org; Mon, 26 Nov 2018 15:12:06 -0500 Received: from debbugs.gnu.org ([208.118.235.43]:45905) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gRNEg-0002qw-NM for guix-patches@gnu.org; Mon, 26 Nov 2018 15:12:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gRNEg-0002SL-Fh for guix-patches@gnu.org; Mon, 26 Nov 2018 15:12:02 -0500 Subject: [bug#33508] [PATCH] gnu: Add ability to restart services on system reconfigure Resent-Message-ID: References: <87efb8m5gy.fsf@zancanaro.id.au> <871s78ypr9.fsf@lassieur.org> From: Carlo Zancanaro In-reply-to: <871s78ypr9.fsf@lassieur.org> Date: Tue, 27 Nov 2018 07:11:00 +1100 Message-ID: <875zwj8uqz.fsf@zancanaro.id.au> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed 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: =?UTF-8?Q?Cl=C3=A9ment?= Lassieur Cc: 33508@debbugs.gnu.org Hey Cl=C3=A9ment! On Mon, Nov 26 2018, Cl=C3=A9ment Lassieur wrote: > It might be safer to 'reload' some services, rather than=20 > 'restarting' them. E.g. for nginx and prosody. Do you think it=20 > would be possible add a 'custom' value that would point to a=20 > custom Shepherd action? I can add this, but I don't think this is as useful as it=20 initially sounds. Most of our services are a specific version of a=20 service pointing to a specific version of a configuration file=20 (ie. that's in the store). That means that a "reload" shepherd=20 action won't be able to know where the new configuration file is=20 to load it. We could solve this in one of two ways: 1) by allowing an arbitrary procedure as the value of=20 restart-strategy, because it can then call a shepherd action with=20 the appropriate configuration file, but then our action will have=20 to detect whether the binary has been changed (which would also=20 detect any dependencies changing). This may also lead to an=20 inconsistent user experience where a "reconfigure" might lead to a=20 reload, or might lead to a restart, and it's not obvious which it=20 will be. 2) by changing our services to create configuration files in a=20 known location (ie. /etc/nginx/nginx.conf). This would make it so=20 a simple "reload" action in the service could meaningfully reload=20 the service, but only if the binary was unchanged (because the old=20 binary might not be able to read the new configuration format, for=20 instance). This still leads to the above problem around the=20 inconsistent user experience, and adds some complexity in terms of=20 how configuration files are managed. I lean towards option (1), because it gives us the ability to call=20 a shepherd action if we want, but also allows us to do arbitrary=20 other things with the extra knowledge on the Guix side. In the end, though, I'm unconvinced that this is a useful thing to=20 add. What do you think? Carlo