guix-daemon fails to start in Childhurd

  • Done
  • quality assurance status badge
Details
2 participants
  • Jan Nieuwenhuizen
  • Mathieu Othacehe
Owner
unassigned
Submitted by
Jan Nieuwenhuizen
Severity
normal
J
J
Jan Nieuwenhuizen wrote on 20 Sep 2020 17:05
(address . bug-guix@gnu.org)(name . Mathieu Othacehe)(address . othacehe@gnu.org)
87y2l47ake.fsf@gnu.org
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

Toggle snippet (15 lines)
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"

a Hurd VM built with

Toggle snippet (3 lines)
./pre-inst-env guix system disk-image --target=i586-pc-gnu gnu/system/examples/bare-hurd.tmpl

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@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com| Avatar® http://AvatarAcademy.com
M
M
Mathieu Othacehe wrote on 21 Sep 2020 10:30
(name . Jan Nieuwenhuizen)(address . janneke@gnu.org)(address . 43533-done@debbugs.gnu.org)
87a6xjbkfy.fsf@gnu.org
Hello janneke,

Toggle quote (7 lines)
> 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
Closed
J
J
Jan Nieuwenhuizen wrote on 21 Sep 2020 10:41
(name . Mathieu Othacehe)(address . othacehe@gnu.org)(address . 43533-done@debbugs.gnu.org)
87sgbbr07k.fsf@gnu.org
Mathieu Othacehe writes:

Hello Mathieu,

Toggle quote (22 lines)
>> 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!

Toggle quote (2 lines)
> 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@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com| Avatar® http://AvatarAcademy.com
Closed
?
Your comment

This issue is archived.

To comment on this conversation send an email to 43533@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 43533
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch