bug#55898: Services depending on new Shepherd features may fail until reboot

[Ludovic Courtès]

Hi!

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

>> 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.

Yes.  The issue is that we’re more free-style than systemd: we’re
basically loading code live in the running Shepherd.  So we have to
write that code such that it works with older Shepherd versions.

This is why we have things like conditions on

  (defined? 'make-inetd-constructor)

and the likes, with a fallback.

>> 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.

I think any upgrade, be it ‘guix system reconfigure’ or ‘apt
dist-upgrade’, is likely to end up loading new service definitions—Guix
System isn’t more aggressive in that respect.

The main difference is that our services are code and that they might
depend on specific Shepherd APIs.  It’s a much more direct dependency
compared to .service files I guess.

Thanks,
Ludo’.