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@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