guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A Critique of Shepherd Design


From: Ludovic Courtès
Subject: Re: A Critique of Shepherd Design
Date: Mon, 22 Mar 2021 18:02:44 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)

Hi,

raid5atemyhomework <raid5atemyhomework@protonmail.com> skribis:

> I'm not sure you can afford to keep it simple.

It has limitations but it does the job—just like many other init systems
did the job before the advent of systemd.

> Consider: https://issues.guix.gnu.org/47253
>
> In that issue, the `networking` provision comes up potentially *before* the 
> network is, in fact, up.  This means that other daemons that require 
> `networking` could potentially be started before the network connection is up.

The ‘networking’ service is just here to say that some network interface
is up or will be up.  It’s admittedly vague and weak, but it’s enough
for most daemons; they just need to be able to bind and listen to some
port.

> One example of such a daemon is `transmission-daemon`.  This daemon will bind 
> itself to port 9091 so you can control it.  Unfortunately, if it gets started 
> while network is down, it will be unable to bind to 9091 (so you can't 
> control it) but still keep running.  On my system that means that on reboot I 
> have to manually `sudo herd restart trannsmission-daemon`.

Could you report a bug for this one?  I don’t see why it’d fail to bind.

> In another example, I have a custom daemon that I have set up to use
> the Tor proxy over 127.0.0.1:9050.  It requires both `networking` and
> `tor`.  When it starts after `networking` comes up but before the
> actual network does, it dies because it can't access the proxy at
> 127.0.0.1:9050 (apparently NetworkManager handles loopback as well).

Loopback is handled by the ‘loopback’ shepherd service, which is
provided via ‘%base-services’.  Perhaps you just need to have your
service depend on it?

> Switching to a concurrent design for Shepherd --- *any* concurrent design --- 
> is probably best done sooner rather than later, because it risks strongly 
> affecting customized `configuration.scm`s like mine that have almost a half 
> dozen custom Shepherd daemons.

I suspect the main issue here is undeclared dependencies of some of the
Shepherd services you mention.

I like the “sooner rather than later” bit, though: it sounds like you’re
about to send patches or announce some sponsorship program?…  :-)

Thanks,
Ludo’.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]