GNU bug report logs - #33508
[PATCH] gnu: Add ability to restart services on system reconfigure

Previous Next

Full log

View this message in rfc822 format

From: Carlo Zancanaro <carlo <at> zancanaro.id.au>
To: Clément Lassieur <clement <at> lassieur.org>
Cc: 33508 <at> debbugs.gnu.org
Subject: [bug#33508] [PATCH] gnu: Add ability to restart services on system reconfigure
Date: Tue, 27 Nov 2018 07:11:00 +1100

Hey Clément!

On Mon, Nov 26 2018, Clément Lassieur wrote:
> It might be safer to 'reload' some services, rather than 
> 'restarting' them.  E.g. for nginx and prosody.  Do you think it 
> would be possible add a 'custom' value that would point to a 
> custom Shepherd action?

I can add this, but I don't think this is as useful as it 
initially sounds. Most of our services are a specific version of a 
service pointing to a specific version of a configuration file 
(ie. that's in the store). That means that a "reload" shepherd 
action won't be able to know where the new configuration file is 
to load it.

We could solve this in one of two ways:

1) by allowing an arbitrary procedure as the value of 
restart-strategy, because it can then call a shepherd action with 
the appropriate configuration file, but then our action will have 
to detect whether the binary has been changed (which would also 
detect any dependencies changing). This may also lead to an 
inconsistent user experience where a "reconfigure" might lead to a 
reload, or might lead to a restart, and it's not obvious which it 
will be.

2) by changing our services to create configuration files in a 
known location (ie. /etc/nginx/nginx.conf). This would make it so 
a simple "reload" action in the service could meaningfully reload 
the service, but only if the binary was unchanged (because the old 
binary might not be able to read the new configuration format, for 
instance). This still leads to the above problem around the 
inconsistent user experience, and adds some complexity in terms of 
how configuration files are managed.

I lean towards option (1), because it gives us the ability to call 
a shepherd action if we want, but also allows us to do arbitrary 
other things with the extra knowledge on the Guix side.

In the end, though, I'm unconvinced that this is a useful thing to 
add. What do you think?

Carlo

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.