all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Ludovic Courtès" <ludo@gnu.org>
To: Jan Nieuwenhuizen <janneke@gnu.org>
Cc: guix-devel@gnu.org, 40006@debbugs.gnu.org
Subject: Re: 33/33: daemon: Workaround issues for the Hurd.
Date: Thu, 12 Mar 2020 13:59:55 +0100	[thread overview]
Message-ID: <8736advid0.fsf@gnu.org> (raw)
In-Reply-To: <87o8t2qcso.fsf@gnu.org> (Jan Nieuwenhuizen's message of "Thu, 12 Mar 2020 07:59:03 +0100")

Hi!

Jan Nieuwenhuizen <janneke@gnu.org> skribis:

> Ludovic Courtès writes:
>
> Hello!
>
>> Jan Nieuwenhuizen <janneke@gnu.org> skribis:
>>
>>>>> +#if !__GNU__
>>>>>      int status = pid.wait(true);
>>>>>      if (status != 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) binutils-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
>> ‘--disable-chroot’, then I think build users are not used at all, right?
>
> It seems that they are; I'm running

Oh, OK.

[…]

>> Other options:
>>
>>   1. Implement clone(2) with CLONE_NEW* in libc on GNU/Hurd.
>>
>>   2. Add a “sandbox” abstraction in the daemon, with OS-specific
>>      implementations of the abstraction (the Nix daemon did that at some
>>      point, with the goal of supporting proprietary macOS etc.)
>>
>>      For GNU/Linux, it’d 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/856e86f2105417363b85b4d7c4d3141f9e81fb56
>
> 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..

I suppose the commit you link to could have been used by libc to
implement #1?  Oh, actually, IIRC, Manolis was working on implementing
mount(2) and umount(2) in libc (which would also be needed), and
probably the settrans utilities were part of that effort.

Thanks,
Ludo’.

  parent reply	other threads:[~2020-03-12 13:00 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20200310075832.7126.86402@vcs0.savannah.gnu.org>
     [not found] ` <20200310075845.291F421123@vcs0.savannah.gnu.org>
2020-03-10  8:54   ` 08/33: gnu: make: Revert to 4.1 for the Hurd Ludovic Courtès
2020-03-10  9:16     ` Jan Nieuwenhuizen
     [not found] ` <20200310075844.240A021123@vcs0.savannah.gnu.org>
2020-03-10  8:55   ` 05/33: gnu: hurd: Fix hurd-target? Ludovic Courtès
2020-03-10 11:22     ` Jan Nieuwenhuizen
     [not found] ` <20200310075846.1DA6821123@vcs0.savannah.gnu.org>
2020-03-10  9:02   ` 11/33: gnu: glibc: Add and update patches for the Hurd Ludovic Courtès
2020-03-10 11:28     ` Jan Nieuwenhuizen
     [not found] ` <20200310075853.45FCC21252@vcs0.savannah.gnu.org>
2020-03-10  9:04   ` 33/33: daemon: Workaround issues " Ludovic Courtès
2020-03-10 12:54     ` Jan Nieuwenhuizen
2020-03-11 14:50       ` Ludovic Courtès
2020-03-12  6:59         ` Jan Nieuwenhuizen
2020-03-12 12:59           ` bug#40006: " Ludovic Courtès
2020-03-12 12:59           ` Ludovic Courtès [this message]
2020-03-12  6:59         ` Jan Nieuwenhuizen
     [not found] ` <20200310075847.6059A2112F@vcs0.savannah.gnu.org>
2020-03-10  9:06   ` 15/33: gnu: coreutils: Remove libcap dependency " Ludovic Courtès
2020-03-11 15:01     ` Jan Nieuwenhuizen
2020-03-11 18:09       ` Vincent Legoll
2020-03-11 19:43         ` Jan Nieuwenhuizen
2020-03-12 13:01       ` Ludovic Courtès
2020-03-14  8:28         ` bug#40006: " Jan Nieuwenhuizen
2020-03-14  8:28         ` Jan Nieuwenhuizen
     [not found] ` <20200310075851.4497E2125F@vcs0.savannah.gnu.org>
2020-03-10  9:10   ` 27/33: gnu: commencement: glibc-intermediate: Build fixes " Ludovic Courtès
2020-03-10 12:45     ` Jan Nieuwenhuizen
     [not found] ` <20200310075850.035F02125B@vcs0.savannah.gnu.org>
2020-03-10  9:13   ` 23/33: gnu: commencement: gcc-boot0: Build fix " Ludovic Courtès
2020-03-10  9:18     ` Efraim Flashner
2020-03-10 13:53       ` Jan Nieuwenhuizen
2020-03-11 14:27         ` Jan Nieuwenhuizen
2020-03-11 15:14           ` Efraim Flashner
2020-03-11 16:20             ` Jan Nieuwenhuizen
2020-03-11 16:27               ` Efraim Flashner
2020-03-12  7:02                 ` Jan Nieuwenhuizen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8736advid0.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=40006@debbugs.gnu.org \
    --cc=guix-devel@gnu.org \
    --cc=janneke@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.