Hello, Apr 16, 2025, 20:19 by [email protected]:
> Well there’s ‘guix publish’, and otherwise the examples from > ‘tests/systemd.sh’ (following ‘define %command’). > > Otherwise we could mimic it by writing a C program that that opens a > SOCK_NONBLOCK socket, binds + listens + select(2) until something > happens, then calls fcntl(2) to clear the O_NONBLOCK flag, and then > forks + execs and call accept(2) in the child process. > > Ludo’. > I tested guix-publish and that had no issues. Some checks I did yesterday with guix-dameon: - Shepherd is passing a blocking socket - The "fdSocket" in "acceptConnection" is always blocking. - the "remote" socket in "acceptConnection" is O_NONBLOCK on the first connection only. - Then also the "from.fd" socket in "processConnection" is O_NONBLOCK on the first connectionThis then causes EAGAIN on trying to read the clientVersion. On linux none of this is an issue. Adding the same check as for the fd 3 socket for O_NONBLOCK to the "connection" socket after accept to tests/systemd.sh passes on Linux but causes a failure on the Hurd. Is glibc accept doing something weird? I am struggling to understand how the first connection would be any different than subsequent ones (and only in the #:lazy-start? #t case) I am unsure what to do about this because shepherd seems to do everything correctly. I saw that ci.g.g.o has started to build i586-gnu substitutes (in particular gcc-final) but if you are restarting the builders more aggressively now then each first build will fail because of this and idk if cuirass can reschedule builds on such failures. Maybe the easiest is to to expose the #:lazy-start? option for now and disable it for guix-daemon in %base-services/hurd ?
