GNU bug report logs - #55898
Services depending on new Shepherd features may fail until reboot

Previous Next

Full log

View this message in rfc822 format

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Maxime Devos <maximedevos <at> telenet.be>, 55898 <at> debbugs.gnu.org
Subject: bug#55898: Services depending on new Shepherd features may fail until reboot
Date: Thu, 21 Jul 2022 00:10:12 -0400

Hi Ludovic,

Ludovic Courtès <ludo <at> gnu.org> writes:

> Hi!
>
> Maxim Cournoyer <maxim.cournoyer <at> 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 saw that used somewhere, but I still think a minimally required
Shepherd version field could be of use on services, for the following
reasons:

1. Otherwise each services are left implementing ad-hoc solutions.

2. It's more complicated to be compatible with two Shepherd version than
simply mentioning the minimum version required, and prevent the service
from running until it is satisfied (especially on a system like Guix
System where we *know* what is the current version of Shepherd
available).

Thanks,

Maxim

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.