[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#33508] [PATCH] gnu: Add ability to restart services on system recon
From: |
Carlo Zancanaro |
Subject: |
[bug#33508] [PATCH] gnu: Add ability to restart services on system reconfigure |
Date: |
Tue, 27 Nov 2018 07:11:00 +1100 |
User-agent: |
mu4e 1.0; emacs 26.1 |
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