Re: A basic Shepherd bug?

[Attila Lendvai]

hi Felix,


> > you should follow the instructions in [1]; namely:
> > 
> > https://lists.gnu.org/archive/html/guix-devel/2023-12/msg00018.html
> > 
> > together with "Installing development snapshots with Guix" in
> > shepherd's README to add shepherd's channel.
> 
> 
> I did so on a production system which I do not reboot often. Two days
> ago, I reconfigured and saw a new Shepherd version being deployed. It
> used up a lot of CPU cycles until I rebooted.


just to clarify: you `guix system reconfigure` into a new shepherd version, and 
after that the currently running shepherd init process went 100% CPU, i.e. it 
was busy looping in one thread?


> It makes sense that upgrading the Shepherd requires a reboot, but maybe
> a warning somewhere would be appropriate, if possible. Maybe an email to
> root?


unfortunately a lot of the infrastructure around guix is lacking explicit 
formal description of dependencies/requirements. e.g. there's nothing (that i 
know of) in the shepherd config files (which are generated by `guix system 
reconfigure`) about what shepherd version they require/assume.

a quick and dirty solution here could be to manually emit an assert into the 
config file that there's an exact match between the shepherd that generated the 
config file, and the shepherd process trying to load it. a warning could be 
issued that the shepherd process is unable to load/process the generated config 
file until a reboot... which would probably be overkill in most cases.

https://ngnghm.github.io/

this^ blog has interesting thoughts on migration and staged computation. it's a 
most interesting vision of how these abstractions could be formally captured, 
and what the resulting computing system would look like.

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“Love and do what you will.”
        — Augustine of Hippo (354–430), 'A sermon on love'