Hi Attila, Attila Lendvai <att...@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’.