bug#22039: [PATCH] 'guix system reconfigure' must start/restart/stop services

[Carlo Zancanaro]

Hey Ludo’,

On Fri, Sep 21 2018, Ludovic Courtès wrote:
> What would you put there?  Do you have concrete examples?

I would have three possible values: 'never, 'always, 'manual.

'never would mean that the service should never be restarted. This 
is for things like udev, or the filesystems, which should never be 
restarted on a running system.

'always would mean that the service is always safe to restart. I 
don't immediately know what services would fit in this category 
(maybe sshd, given Efraim's comment; maybe ntpd? I'm sure there 
are others). Things like nginx will probably not fall into this 
category, because they involve some downtime when restarting. 
Reloading their configuration (via a "reload" action, or similar) 
is not enough because the binary and/or libraries might have 
changed (and, in the worst case, might have an incompatible 
configuration format, although I would expect that to be 
exceedingly rare).

'manual would mean that the service should be restarted, but it 
need to be done at an appropriate time. This should prompt the 
user with the names of the services, and we should provide an 
option to guix system reconfigure to restart these services as 
part of the reconfigure. We could call the option 
"--restart-services".

> > [ ... ] I just have to know that to restart wicd I have to run 
> > "herd restart networking".
>
> There’s ‘guix system search’ that provides this kind of info 
> (see <https://issues.guix.info/issue/29707>), but I agree we 
> could do better.

I actually checked this before sending my previous message, but I 
didn't see that it includes "shepherdnames". I tested with "guix 
system search wicd" which didn't show any, but I see now that 
searching "guix system search xmpp" does helpfully show how to 
restart the service.

> We can go with your patch and a message along the lines of what 
> we discussed above, and then work on the improvements you 
> mentioned, one at a time.  That way we’ll have the warm feeling 
> of having achieved something, even if there’s more to come.  :-)

I won't be able to look at writing the code for this for a few 
weeks, but hopefully I'll get to it around mid- to late-October.

Carlo