[Top][All Lists]

[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?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]