From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Nieuwenhuizen Subject: Re: 33/33: daemon: Workaround issues for the Hurd. Date: Thu, 12 Mar 2020 07:59:03 +0100 Message-ID: <87o8t2qcso.fsf@gnu.org> References: <20200310075832.7126.86402@vcs0.savannah.gnu.org> <20200310075853.45FCC21252@vcs0.savannah.gnu.org> <87v9ncwpg4.fsf@gnu.org> <87k13s2wwl.fsf@gnu.org> <87h7yvgd3h.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:33565) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jCHoF-0007uY-LC for guix-devel@gnu.org; Thu, 12 Mar 2020 02:59:13 -0400 In-Reply-To: <87h7yvgd3h.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Wed, 11 Mar 2020 15:50:26 +0100") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane-mx.org@gnu.org Sender: "Guix-devel" To: Ludovic =?utf-8?Q?Court=C3=A8s?= Cc: guix-devel@gnu.org, 40006@debbugs.gnu.org Ludovic Court=C3=A8s writes: Hello! > Jan Nieuwenhuizen skribis: > >>>> +#if !__GNU__ >>>> int status =3D pid.wait(true); >>>> if (status !=3D 0) >>>> throw Error(format("cannot kill processes for uid `%1%': %2%"= ) % uid % statusToString(status)); >>>> +#endif >>> >>> Do you know what the rationale was? It looks like it could leave >>> zombies behind us. >> >> No, maybe Manolis knows? What I do know is why I used the patch: before >> applying this patch I could only build up to binutils-boot0. >> binutils-boot0 would always fail like so >> >> ./pre-inst-env guix build -e '(@@ (gnu packages commencement) binuti= ls-boot0)' --no-offload >> XXX fails: Workaround for nix daemon >> phase `compress-documentation' succeeded after 0.4 seconds >> error: cannot kill processes for uid `999': Operation not permitted >> guix build: error: cannot kill processes for uid `999': failed with exit= code 1 > > But is the build process actually running as UID 999? If you pass > =E2=80=98--disable-chroot=E2=80=99, then I think build users are not used= at all, right? It seems that they are; I'm running sudo ./pre-inst-env guix-daemon --disable-chroot --build-users-group=3D= guixbuild & and when starting two build processes, I get =E2=94=94=E2=94=80sudo(744,root)=E2=94=80=E2=94=80=E2=94=80guix-daemon(= 746)=E2=94=80 / =E2=94=80=E2=94=AC=E2=94=80guix-daemon(1484)=E2=94=80=E2=94=AC=E2= =94=80guile(1487,guixbuilder01)=E2=94=80 / =E2=94=82 =E2=94=94=E2=94=80guile-2.2(1485) =E2=94=94=E2=94=80guix-daemon(1787)=E2=94=80=E2=94=AC=E2=94=80guil= e(2203,guixbuilder02)=E2=94=80 / =E2=94=80=E2=94=80bash(1497)=E2=94=80=E2=94=80=E2=94=80bash(396= 4) =E2=94=80=E2=94=80make(2512)=E2=94=80=E2=94=80=E2=94=80gcc(6043= )=E2=94=80=E2=94=80=E2=94=80cc1(6048) guixbuilder01 is 999, guixbuilder02 is 998 etc. Does this mean that root cannot pid.wait() for the builders? Note that this error does not occ= ur when building gnu-make-boot0 or diffutils-boot0. Hmm, after some more playing on the Hurd and our conversation on IRC, I found that kill -1 simply does not work at the moment. I copied sysdeps/mach/hurd/kill.c, renamed __kill to debug_kill and added --8<---------------cut here---------------start------------->8--- // libc_hidden_def (__kill) // weak_alias (__kill, kill) int main () { return debug_kill (-1, SIGKILL); } --8<---------------cut here---------------end--------------->8--- Running this as a dummy user, it turns out we run err =3D __proc_getpgrppids (proc, - pid, &pids, &npids); (effectively asking for PIDs in group of PID=3D1 ??) and returns only one PID, in my case 5292 --8<---------------cut here---------------start------------->8--- demo@debian:~$ ps -ef -p 5292 USER PID PPID TTY TIME COMMAND - 5292 5 - 0:00.00 /hurd/storeio -Tzero --8<---------------cut here---------------end--------------->8--- Hmm? So it seems that kill -1 is currently not supported, or buggy. I'll look/ask into this some more today. >> -#define CHROOT_ENABLED HAVE_CHROOT && HAVE_SYS_MOUNT_H && defined(MS_BI= ND) && defined(MS_PRIVATE) && defined(CLONE_NEWNS) && defined(SYS_pivot_roo= t) >> +#define CHROOT_ENABLED HAVE_CHROOT && HAVE_SYS_MOUNT_H && defined(MS_BI= ND) && defined(MS_PRIVATE) >> +#define CLONE_ENABLED defined(CLONE_NEWNS) >> + >> +#if defined(SYS_pivot_root) >> +#define pivot_root(new_root, put_old) (syscall(SYS_pivot_root, new_root= ,put_old)) >> +#endif >>=20=20 >> #if CHROOT_ENABLED >> #include >> @@ -2005,7 +2010,7 @@ void DerivationGoal::startBuilder() >> - The UTS namespace ensures that builders see a hostname of >> localhost rather than the actual hostname. >> */ >> -#if CHROOT_ENABLED >> +#if CLONE_ENABLED >> if (useChroot) { >> char stack[32 * 1024]; >> int flags =3D CLONE_NEWPID | CLONE_NEWNS | CLONE_NEWIPC | CLONE_NEWUTS= | SIGCHLD; > > I=E2=80=99m not sure this is correct. Perhaps we rather need an =E2=80= =9C#ifdef > __linux__=E2=80=9D around the use of clone(2)? Okay, let's do that for now. > Other options: > > 1. Implement clone(2) with CLONE_NEW* in libc on GNU/Hurd. > > 2. Add a =E2=80=9Csandbox=E2=80=9D abstraction in the daemon, with OS-s= pecific > implementations of the abstraction (the Nix daemon did that at some > point, with the goal of supporting proprietary macOS etc.) > > For GNU/Linux, it=E2=80=99d use chroot(2)+clone(NEWNS) etc. as root. > > On GNU/Hurd, it could spawn the process in a sub-Hurd, i.e., with > its own proc server, root file system server, and without a pfinet > server running. > > Option #2 can be fun to implement and probably easier and less > controversial than Option #1. However, it does mean adding more code of > the C++ code base, which is sad. I'm assuming that 1.is what Manolis wanted to support with his libhurdutil? In fact, I forward ported (minimal effort) the patch https://gitlab.com/janneke/hurd/-/commit/856e86f2105417363b85b4d7c4d314= 1f9e81fb56 but haven't tried linking against this yet. That would be a nice first step. 2. sounds fun, but it would need more getting familiar with the Hurd for me :-) You never know.. > Either way, it=E2=80=99s a bit of work, so this can definitely come later. Great! I have just reset wip-hurd again with new attempts for these too; all somewhat and more experimental patches are at https://gitlab.com/janneke/guix/-/tree/wip-hurd-system Greetings, janneke --=20 Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar=C2=AE http://AvatarAcademy.com