GNU bug report logs - #43650
[PATCH 0/8] Assorted childhurd improvements

Previous Next

Package: guix-patches;

Reported by: Ludovic Courtès <ludo <at> gnu.org>

Date: Sun, 27 Sep 2020 15:30:02 UTC

Severity: normal

Tags: patch

Done: Ludovic Courtès <ludo <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


Message #56 received at 43650 <at> debbugs.gnu.org (full text, mbox):

From: Jan Nieuwenhuizen <janneke <at> gnu.org>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 43650 <at> debbugs.gnu.org
Subject: Re: [bug#43650] [PATCH 4/8] services: hurd-vm: Check whether
 /dev/kvm exists at run time.
Date: Tue, 29 Sep 2020 16:22:02 +0200
[Message part 1 (text/plain, inline)]
Ludovic Courtès writes:

Hello,

> I’ve pushed ‘wip-childhurd’ with a few additional commits.

Great, this works/fixes it for me!  Using the attached
bare+childhurd.tmpl, I can build and start a Guix VM with a childhurd:

--8<---------------cut here---------------start------------->8---
$ $(./pre-inst-env guix system vm gnu/system/examples/bare+childhurd.tmpl) \
  -m 1G --nographic --net nic \
  --net user,hostfwd=tcp:127.0.0.1:12022-:2222,hostfwd=tcp:127.0.0.1:13022-:10022
--8<---------------cut here---------------end--------------->8---

and then, after half a minute or so:

--8<---------------cut here---------------start------------->8---
$ ssh -p 13022 localhost


  This is the GNU Hurd.  Welcome.

root <at> childhurd ~#
--8<---------------cut here---------------end--------------->8---

> The flaky startup issue appears to be fixed by:
>
>   88946005d7 * services: secret-service: Add initial client/server handshake.
>
> Before that, what would happen is that:
>
>   1. The host would connect(2) to QEMU as soon as QEMU is running;
>      connect(2) would succeed immediately and so the host would send its
>      secrets right away, disconnect, and move on.
>
>      However, at that point, the guest is still booting and its secret
>      service server is not even accept(2)ing yet.  Looks like QEMU’s
>      SLIRP would more or less buffer the packets the host sent, “more or
>      less” being the important point.
>
>   2. The guest would eventually accept(2), which would succeed.  Then it
>      would sometimes receive stuff, sometimes not, depending on what
>      happened with the SLIRP buffering I suppose.

Ah, thanks for the explanation...that makes sense.

> Consequently, it can take ~20s for the ‘start’ method of the childhurd
> to succeed.  Eventually, when shepherd runs on Fibers or similar, it
> won’t be a problem, but for now it means that PID 1 remains stuck in
> select(2) for this many seconds.

Yeah...Anyway LGTM!

Greetings,
Janneke

[bare+childhurd.tmpl (application/octet-stream, attachment)]
[Message part 3 (text/plain, inline)]
-- 
Jan Nieuwenhuizen <janneke <at> gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

This bug report was last modified 4 years and 239 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.