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

Previous Next

Full log

Message #60 received at 55898 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#55898: Services depending on new Shepherd features may fail
 until reboot
Date: Thu, 01 Sep 2022 15:16:33 -0400

Hi,

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

> Howdy!
>
> Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis:
>
>> I had something different on mind; I was thinking of some added field to
>> our shepherd-service object where the minimal version of Shepherd
>> required could be specified, e.g. "0.9.1".
>>
>> The check could be abstracted in the shepherd-service implementation,
>> avoiding services writers to handle that by themselves in *each* service
>> requiring so.
>
> Hmm I see.
>
>> The benefit would be an improved user experience, and cleaner service
>> code.  Upon reconfiguring a machine not yet equipped with a new enough
>> Shepherd, Shepherd could print:
>>
>> The x, y and z services won't be started until the next reboot, as they
>> require a newer Shepherd version.
>>
>> Instead of seeing the new services fail to run without (for the end
>> user) without any obvious reason.
>
> Currently, new services don’t fail to run: we arrange so that new
> services always “work”, whether they’re talking to an old shepherd or a
> new one.  The user experience (bugs aside) should be good: services are
> always reloaded.

This depends on how the services are written, and how much care to this
edge case their author put into writing it.  I know the Jami service
type won't run without Shepherd >= 0.9.0, and the solution is not
obvious (I'm suspecting sleep* from (guix build dbus-service) should use
regular sleep when shepherd is < 0.9.0.).

> IIUC, in the model you propose, we’d sacrifice this, by admitting that
> in some cases we just won’t load services live and instead tell users to
> reboot; the benefit would be cleaner service code.
>
> It’s a tradeoff; the cost/benefit ratio is not obvious to me.

Having a simple way to cleanly mark a service as "requiring Shepherd
0.9.X" would provide good value in my opinion, for when adding backward
compatibility is too difficult or not desirable for any reason (such as
causing long 'hangs' while busy-waiting for a process to start in older
shepherds).

Thanks,

Maxim

Previous Next

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