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

[Ludovic Courtès]

Hello,

Carlo Zancanaro <address@hidden> skribis:

>> From the POV of the Shepherd, services carry no semantics.
>
> In Guix we have as much information as possible about the services. We
> should be know which services should be upgraded automatically, which
> ones we should prompt the user to upgrade, and which ones are never
> safe to upgrade. Maybe we could add a "restart-strategy" to the
> shepherd-service object?

What would you put there?  Do you have concrete examples?

Note that FHS distros don’t do better: either the service is
hot-replaceable (nginx; I don’t know of any other) or can at least
reload its config (sshd, etc.), and then it’s dynamically upgraded, or
it’ll be upgraded next time you restart it.

That’s because fundamentally only the user can tell whether now is a
good time to restart, say, sshd.

In Debian, “apt-get dist-upgrade” opens a dialog box asking the user
whether services can be restarted right away, IIRC.

>> Thus I think it’s reasonable to print a message along the lines of:
>>
>>   The following services were upgraded: …
>>   Please run “herd restart SERVICE” to stop, upgrade, and   restart
>> services that were not automatically upgraded.
>>
>> WDYT?
>
> The main reasons I'm not super happy with this are that it's not
> discoverable (which is bad for new users), and it requires interaction
> (so cannot be an unattended upgrade).

I agree, but I don’t think full unattended upgrades exist out there.
I’m not saying this is good, but rather that this is hard and beyond
the scope of this patch.

> In particular for discoverability, some of our services don't take
> advantage of the Shepherd's ability to have multiple "provision"
> values. For instance, 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.

> Maybe this should be a separate ticket. Replacing the services and
> printing a generic message will still be an improvement on what Guix
> currently does, and I don't want to hold that up just because I think
> we can do better.

Yes, I think this should be a separate ticket.  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.  :-)

Thank you!

Ludo’.