emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#43533: closed (guix-daemon fails to start in Childhurd)


From: GNU bug Tracking System
Subject: bug#43533: closed (guix-daemon fails to start in Childhurd)
Date: Mon, 21 Sep 2020 08:32:02 +0000

Your message dated Mon, 21 Sep 2020 10:30:57 +0200
with message-id <87a6xjbkfy.fsf@gnu.org>
and subject line Re: guix-daemon fails to start in Childhurd
has caused the debbugs.gnu.org bug report #43533,
regarding guix-daemon fails to start in Childhurd
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
43533: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=43533
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
--- Begin Message --- Subject: guix-daemon fails to start in Childhurd Date: Sun, 20 Sep 2020 17:05:37 +0200 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)
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@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | AvatarĀ® http://AvatarAcademy.com



--- End Message ---
--- Begin Message --- Subject: Re: guix-daemon fails to start in Childhurd Date: Mon, 21 Sep 2020 10:30:57 +0200 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)
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


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]