bug#55898: jami service failing following 'guix deploy' update

[Maxim Cournoyer <maxim.cournoyer@gmail.com>]

Hi again,

[...]

> Perhaps services should allow specifying the minimum required Shepherd
> version, which Shepherd could ensure is met before attempting to restart
> a service, printing something like:
>
> 'Could not restart service X due to unmet Shepherd version requirement;
> the service will continue unchanged until the next reboot'
>
> or something similar.
>
> I've re-titled the bug, as this isn't specific to our jami service.

I've asked in #systemd about what a similar situation would happen in
systemd-land, and here's what I've learned:

1. service units aren't reloaded automatically after new versions of
them are installed -- this effectively prevent the breakage seen here
(the jami service was reloaded and restarting manually it caused it to
fail).

2. a savvy user can still opt to force the new service to be reloaded
via 'systemctl daemon-reload'.  In case the service update depends on
new systemd features, systemd would need to be restarted itself, via
'systemctl daemon-reexec'.   The later command is interesting, but its
documented as a debugging tool [0]:

  daemon-reexec

    Reexecute the systemd manager. This will serialize the manager
    state, reexecute the process and deserialize the state again. This
    command is of little use except for debugging and package
    upgrades. Sometimes, it might be helpful as a heavy-weight
    daemon-reload. While the daemon is being reexecuted, all sockets
    systemd listening on behalf of user configuration will stay
    accessible.

[0]  https://www.freedesktop.org/software/systemd/man/systemctl.html#

systemd folks told me it is not typically run in systemd package upgrade
hooks, but perhaps some distribution do this (I don't know).

So the situation is not very different in systemd vs shepherd, except
that we more aggressively load the new service definitions, potentially
leading to breakage.

Thoughts?

Maxim