[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#55898: Services depending on new Shepherd features may fail until re
From: |
Maxim Cournoyer |
Subject: |
bug#55898: Services depending on new Shepherd features may fail until reboot |
Date: |
Mon, 29 Aug 2022 17:06:36 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) |
Hi Ludovic,
Ludovic Courtès <ludo@gnu.org> writes:
> Hi,
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>
>> Ludovic Courtès <ludo@gnu.org> writes:
>
> [...]
>
>>> 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).
>
> I think it’s a situation similar to “feature tests vs. identity tests”
> in build system configuration (checking whether the libc function you
> want to use is available rather than checking whether ‘uname’ returns
> “Linux”), and for the same reason I tend to prefer feature tests as
> shown above.
Agreed, but the context differs wildly: while Autoconf or browsers for
example really are facing a diversity of configuration, the version of
Shepherd used in Guix System is known and controlled. So the only
problems bound to happen are in this context:
1. New Shepherd version introduced in Guix (package upgrade).
2. New Shepherd features used by services.
3. Machine reconfigured using a commit including 1 and 2.
The problems are temporary: upon a reboot the running Shepherd version
will be the latest, and have all the features needed.
Hence my suggestion to use something simple to improve the user
experience of a user faced with 3.
> I won’t pretend it’s pretty :-), but I don’t see an improvement feasible
> in the short term.
>
> In the long term, maybe we’d want the service API in the Shepherd to be
> more declarative, more like packages in Guix. But that’s more for a 2.0
> horizon IMO.
>
> Perhaps we should close this issue unless it becomes actionable?
It's a relatively narrow use case and it's relatively rare too, but I'd
err on keeping it open until it gets fixed, whether in a definitive
fashion or as a more limited one to help users facing 3. above.
Thanks, and welcome back!
Maxim