bug#53580: shepherd's architecture

[Ludovic Courtès]

Hi Attila,

Attila Lendvai <attila@lendvai.name> skribis:

> [forked from: bug#53580: /var/run/shepherd/socket is missing on an otherwise 
> functional system]
>
>> So I think we’re mostly okay now. The one thing we could do is load
>> the whole config file in a separate fiber, and maybe it’s fine to keep
>> going even when there’s an error during config file evaluation?
>>
>> WDYT?
>
>
> i think there's a fundamental issue to be resolved here, and addressing that 
> would implicitly resolve the entire class of issues that this one belongs to.
>
> guile (shepherd) is run as the init process, and because of that it may not 
> exit or be respawn. but at the same time when we reconfigure a guix system, 
> then shepherd's config should not only be reloaded, but its internal state 
> merged with the new config, and potentially even with an evolved shepherd 
> codebase.

Sorry to be direct: is there a concrete bug you’re reporting here?

> i still lack a proper mental model of all this to succesfully predict what 
> will happen when i `guix system reconfigure` after i `guix pull`-ed my 
> service code, and/or changed the config of my services.

What happens is that ‘guix system reconfigure’ loads new services into
the running shepherd.  New services simply get started; services for
which a same-named service is already running instead get registered as
a “replacement”, meaning that the new version of the service only gets
started when the user explicitly runs ‘herd restart SERVICE’.

Non-stop upgrades is ideal, but shepherd alone cannot do that.  For
instance, nginx supports that, and no init system could implement that
on its behalf.

Ludo’.