From: Maxim Cournoyer <maxim.cournoyer@gmail.com>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: Maxime Devos <maximedevos@telenet.be>, 55898@debbugs.gnu.org
Subject: bug#55898: Services depending on new Shepherd features may fail until reboot
Date: Mon, 29 Aug 2022 17:06:36 -0400 [thread overview]
Message-ID: <8735debvz7.fsf@gmail.com> (raw)
In-Reply-To: <87y1v75fo0.fsf@gnu.org> ("Ludovic Courtès"'s message of "Mon, 29 Aug 2022 15:43:11 +0200")
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
next prev parent reply other threads:[~2022-08-29 21:09 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-11 5:53 bug#55898: jami service failing following 'guix deploy' update Maxim Cournoyer
2022-06-11 14:51 ` Maxime Devos
2022-06-14 19:40 ` Maxim Cournoyer
2022-06-24 17:52 ` Maxim Cournoyer
2022-06-24 18:01 ` bug#55898: jami service failing following reconfigure Maxim Cournoyer
2022-07-06 21:38 ` bug#55898: jami service failing following 'guix deploy' update Maxim Cournoyer
2022-07-06 22:01 ` Maxim Cournoyer
2022-07-20 21:19 ` bug#55898: Services depending on new Shepherd features may fail until reboot Ludovic Courtès
2022-07-21 4:10 ` Maxim Cournoyer
2022-08-29 13:43 ` Ludovic Courtès
2022-08-29 21:06 ` Maxim Cournoyer [this message]
2022-08-30 7:33 ` Ludovic Courtès
2022-08-30 9:35 ` Maxime Devos
2022-08-30 13:50 ` Ludovic Courtès
2022-09-01 13:18 ` Maxim Cournoyer
2022-09-01 13:28 ` Maxime Devos
2022-09-01 13:51 ` Ludovic Courtès
2022-09-01 19:16 ` Maxim Cournoyer
2022-09-02 9:10 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8735debvz7.fsf@gmail.com \
--to=maxim.cournoyer@gmail.com \
--cc=55898@debbugs.gnu.org \
--cc=ludo@gnu.org \
--cc=maximedevos@telenet.be \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).