GNU bug report logs -
#43533
guix-daemon fails to start in Childhurd
Previous Next
Reported by: Jan Nieuwenhuizen <janneke <at> gnu.org>
Date: Sun, 20 Sep 2020 15:07:01 UTC
Severity: normal
Done: Mathieu Othacehe <othacehe <at> gnu.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 43533 in the body.
You can then email your comments to 43533 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#43533
; Package
guix
.
(Sun, 20 Sep 2020 15:07:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Jan Nieuwenhuizen <janneke <at> gnu.org>
:
New bug report received and forwarded. Copy sent to
bug-guix <at> gnu.org
.
(Sun, 20 Sep 2020 15:07:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hi!
On current master (6feb7a2107000f9ded547543dcda9d64402c6081), the
shepherd in a Childhurd fails to start the guix-daemon. It does start
when invoked manually, using the same arguments *)
The culprit seems to be the usage of fork+exec-command/container:
After applying this patch
--8<---------------cut here---------------start------------->8---
diff --git a/gnu/services/base.scm b/gnu/services/base.scm
index d560ad5a13..98a8d2abca 100644
--- a/gnu/services/base.scm
+++ b/gnu/services/base.scm
@@ -1570,7 +1570,7 @@ proxy of 'guix-daemon'...~%")
;; the 'set-http-proxy' action.
(or (getenv "http_proxy") #$http-proxy))
- (fork+exec-command/container
+ (fork+exec-command
(cons* #$(file-append guix "/bin/guix-daemon")
"--build-users-group" #$build-group
"--max-silent-time"
--8<---------------cut here---------------end--------------->8---
a Hurd VM built with
--8<---------------cut here---------------start------------->8---
./pre-inst-env guix system disk-image --target=i586-pc-gnu gnu/system/examples/bare-hurd.tmpl
--8<---------------cut here---------------end--------------->8---
has the shepherd starting the guix-daemon fine.
I found that the /container bit was added in
8ce6f4dc2879919c12bc76a2f4b01200af97e019
installer: Run the installation inside a container.
...but I don't find the commit message quite clear about its intention
to *always* run guix-daemon in a container; it could be read as
sugessting to do so only during installation?
How to proceed reverting this container feature for the Hurd?
Greetings,
Janneke
*) For the Hurd that currently is something like:
GUIX_LOCPATH=/gnu/store/z7a6sbvqzb5zapwpznmjkq2rsxil6i67-glibc-utf8-locales-2.31/lib/locale\
LC_ALL=en_US.utf8\
guix-daemon --build-users-group guixbuild --max-silent-time 0 --timeout 0
--log-compression bzip2 --substitute-urls https://ci.guix.gnu.org
--disable-chroot --disable-deduplication
--
Jan Nieuwenhuizen <janneke <at> gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | AvatarĀ® http://AvatarAcademy.com
Reply sent
to
Mathieu Othacehe <othacehe <at> gnu.org>
:
You have taken responsibility.
(Mon, 21 Sep 2020 08:32:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Jan Nieuwenhuizen <janneke <at> gnu.org>
:
bug acknowledged by developer.
(Mon, 21 Sep 2020 08:32:02 GMT)
Full text and
rfc822 format available.
Message #10 received at 43533-done <at> debbugs.gnu.org (full text, mbox):
Hello janneke,
> 8ce6f4dc2879919c12bc76a2f4b01200af97e019
> installer: Run the installation inside a container.
>
> ...but I don't find the commit message quite clear about its intention
> to *always* run guix-daemon in a container; it could be read as
> sugessting to do so only during installation?
Thanks for the detailed bug report. Yes it's not very clear, I'll try to
improve the comments. The idea is that when you run:
herd start guix-daemon PID
then, the guix-daemon joins the given PID namespaces, which is practical
to solve an installation issue.
If guix-daemon is started normally, outside of the installation process,
then it joins the caller namespaces, which should be a no-op. Of course,
it breaks everything if the operating system does not support
namespaces.
Fixed with 6453915cf7729203ef9552c13cb4528c6f4ed122.
Sorry for the breakage,
Mathieu
Information forwarded
to
bug-guix <at> gnu.org
:
bug#43533
; Package
guix
.
(Mon, 21 Sep 2020 08:43:02 GMT)
Full text and
rfc822 format available.
Message #13 received at 43533-done <at> debbugs.gnu.org (full text, mbox):
Mathieu Othacehe writes:
Hello Mathieu,
>> 8ce6f4dc2879919c12bc76a2f4b01200af97e019
>> installer: Run the installation inside a container.
>>
>> ...but I don't find the commit message quite clear about its intention
>> to *always* run guix-daemon in a container; it could be read as
>> sugessting to do so only during installation?
>
> Thanks for the detailed bug report. Yes it's not very clear, I'll try to
> improve the comments. The idea is that when you run:
>
> herd start guix-daemon PID
>
> then, the guix-daemon joins the given PID namespaces, which is practical
> to solve an installation issue.
>
> If guix-daemon is started normally, outside of the installation process,
> then it joins the caller namespaces, which should be a no-op. Of course,
> it breaks everything if the operating system does not support
> namespaces.
>
> Fixed with 6453915cf7729203ef9552c13cb4528c6f4ed122.
Yay, I can confirm that it works!
> Sorry for the breakage,
Thanks for the quick fix and explanation, I didn't catch that no-op
trick! It's all about context/knowledge I guess; If you know how /ns/
works, I guess that the patch/explanation was clear.
Greetings,
Janneke
--
Jan Nieuwenhuizen <janneke <at> gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | AvatarĀ® http://AvatarAcademy.com
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Mon, 19 Oct 2020 11:24:06 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 188 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.