GNU bug report logs -
#71193
Shepherd fails to start a system when given an incorrect form to the start field of any service
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 71193 in the body.
You can then email your comments to 71193 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-guix <at> gnu.org
:
bug#71193
; Package
guix
.
(Sat, 25 May 2024 07:37:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
"Picnoir" <picnoir <at> alternativebit.fr>
:
New bug report received and forwarded. Copy sent to
bug-guix <at> gnu.org
.
(Sat, 25 May 2024 07:37:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hey Guix,
I'm facing a pretty annoying Shepherd 0.10.4 bug.
If a service start script gets provided an incorrect form, such as an
empty quoted list, Shepherd hangs during its early startup and bricks
the overall Guix system.
I think the following snippet is a good minimal reproducer for this. Add
this service to a guix system configuration:
--8<---------------cut here---------------start------------->8---
(simple-service
'shepherd-bug-repro
shepherd-root-service-type
(list (shepherd-service
(documentation "shepherd hang minimal repro")
(provision '(shepherd-bug-repro))
(requirement '())
(start #~('())))))
u--8<---------------cut here---------------end--------------->8---
⚠ DO NOT BOOT ON A CRITICAL SYSTEM WITH THIS SERVICE, IT'LL BRICK IT ⚠
You can create a VM for this system and start it. The VM hangs after the
log line "creating /etc/machine-id...", before any shepherd service gets
started.
You get the same behaviour if you end up booting by misfortune a "real"
system having this service.
Instead of having the whole system to freeze, I'd expect shepherd to
fail the particular service having an incorrect start form.
I'm not sure what's happening here. I did not manage to diagnose this further,
the shepherd does not seem to be super chatty at this stage of the boot.
Tested on Shepherd 0.10.4 with the Guix revision
c5e63e19ac672f9e63fc8ee98fa9a16f978ce19c.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#71193
; Package
guix
.
(Wed, 26 Jun 2024 13:49:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 71193 <at> debbugs.gnu.org (full text, mbox):
Hi Picnoir,
"Picnoir" <picnoir <at> alternativebit.fr> skribis:
> I think the following snippet is a good minimal reproducer for this. Add
> this service to a guix system configuration:
>
> --8<---------------cut here---------------start------------->8---
> (simple-service
> 'shepherd-bug-repro
> shepherd-root-service-type
> (list (shepherd-service
> (documentation "shepherd hang minimal repro")
> (provision '(shepherd-bug-repro))
> (requirement '())
> (start #~('())))))
> u--8<---------------cut here---------------end--------------->8---
>
> ⚠ DO NOT BOOT ON A CRITICAL SYSTEM WITH THIS SERVICE, IT'LL BRICK IT ⚠
>
> You can create a VM for this system and start it. The VM hangs after the
> log line "creating /etc/machine-id...", before any shepherd service gets
> started.
[...]
> Tested on Shepherd 0.10.4 with the Guix revision
> c5e63e19ac672f9e63fc8ee98fa9a16f978ce19c.
This sounds very much like <https://issues.guix.gnu.org/71144>, which
was fixed in Guix commit cca25a67693bb68a1884a081b415a43fad1e8641,
shortly after the commit you mention.
I tested the reproducer you posted in a VM and it boots fine. The
problem simply leads to an error message in /var/log/messages:
--8<---------------cut here---------------start------------->8---
Jun 26 15:43:09 localhost vmunix: [ 3.574026] shepherd[1]: Exception caught while loading '/gnu/store/c44hd3gfksalrbsgc3a0ax4v9jmnkzb4-shepherd-shepherd-bug-repro.go': #<&compound-exception components: (#<&assertion-failure> #<&origin origin: #f> #<&message message: "Wrong type to apply: ~S"> #<&i
Jun 26 15:43:09 localhost vmunix: [ 3.574132] rritants irritants: (())> #<&exception-with-kind-and-args kind: wrong-type-arg args: (#f "Wrong type to apply: ~S" (()) (()))>)>
Jun 26 15:43:09 localhost vmunix: [ 3.583838] shepherd[1]: starting services...
Jun 26 15:43:09 localhost vmunix: [ 3.585444] shepherd[1]: Configuration successfully loaded from '/gnu/store/8cch4dv5ca1v0hsgyr6d8jay513x7d8g-shepherd.conf'.
--8<---------------cut here---------------end--------------->8---
… and of course the faulty service doesn’t show up at all in ‘herd
status’.
Could you confirm it’s fine for you?
Thanks,
Ludo’.
bug closed, send any further explanations to
71193 <at> debbugs.gnu.org and "Picnoir" <picnoir <at> alternativebit.fr>
Request was from
Ludovic Courtès <ludo <at> gnu.org>
to
control <at> debbugs.gnu.org
.
(Mon, 22 Jul 2024 07:22:03 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Mon, 19 Aug 2024 11:24:12 GMT)
Full text and
rfc822 format available.
This bug report was last modified 203 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.