On Fri, Sep 21, 2018 at 01:58:03PM +0200, Ludovic Courtès wrote: > Hello, > > Carlo Zancanaro 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? Restart/reload/whatever unless explicitly disabled? > > 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. Not exactly the point, but Debian regularly restarts sshd for me on a remote box (somehow) without me losing the connection. > > 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? > This sounds like a really good idea, especially if we limit to ones that are less likely to cause problems if restarted (like filesystems). We still have to figure out something for databases and upgrading them from one version to another. -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted