[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 0/15] Add preliminary support for Linux containers
From: |
Thompson, David |
Subject: |
Re: [PATCH 0/15] Add preliminary support for Linux containers |
Date: |
Tue, 7 Jul 2015 18:35:53 -0400 |
On Tue, Jul 7, 2015 at 6:28 AM, Ludovic Courtès <address@hidden> wrote:
> Howdy!
>
> In short, this is awesome!
>
> Here are random notes I took as I was playing with all this.
>
> David Thompson <address@hidden> skribis:
>
>> The main interface to this functionality is the 'call-with-container'
>> procedure in the (gnu build linux-container) module:
>>
>> (call-with-container
> ^^
> Missing list of mounts here.
Oof. Oversight while I was typing all this up. Sorry!
>> (lambda ()
>> (sethostname "guix-0.8.3"))
>
> Surprisingly, calling ‘getpid’ in the thunk returns the PID of the
> parent (I was expecting it to return 1.) Not sure why that is the
> case. I’m still amazed that this works as non-root, BTW.
The first process created inside the PID namespace gets the honor of
being PID 1, not the process created with the 'clone' call.
For more information, see: https://lwn.net/Articles/532748/
> There’s an issue when the parent’s Guile is not mapped into the
> container’s file system: ‘use-modules’ forms and auto-loading will fail.
> For instance, I did (use-modules (ice-9 ftw)) in the parent and called
> ‘scandir’ in the child, but that failed because of an attempt to
> auto-load (ice-9 i18n), which is unavailable in the container.
Hmm, I don't know of a way to deal with that other than the user being
careful to bind-mount in the Guile modules they need.
Hmm, there's various reasons that EINVAL would be thrown. Could you
readlink "those" files, that is /proc/<pid-outside-container>/ns/user
and /proc/<pid-inside-container>/ns/user, and tell me if the contents
are the same? They shouldn't be, but this will eliminate one of the
possible causes of EINVAL.
>> If that's not exciting enough, how about launching a new development
>> environment inside a container?
>>
>> guix environment --container emacs
>
> This is wonderful. :-)
>
> Currently, $PWD is mapped to /env in the container. I think the default
> should be to map $PWD to $PWD, because often build systems record
> $top_srcdir and $top_builddir and would be confused if you work on a
> given build tree both inside and outside the container.
Sure, I didn't think of that. I will make change it.
> Also, I think we should add --expose and --share as for ‘guix system’,
> though that can come later.
Yes, I also really want that, but it's a task for another time.
> Last, I wonder if there should be an option to use a UID other than 0.
> Then perhaps we’d need to create fake /etc/group and /etc/passwd, as
> done in build.cc.
>
> WDYT?
>
>> Here's how you build it:
>>
>> guix system container container.scm
>
> Very neat. I wonder if that should automatically override the
> ‘file-systems’ field to be ‘%container-file-systems’, so that one can
> reuse existing OS declarations unmodified. WDYT?
This would be a better user experience, for sure. I thought about
this, but I don't know how to do it in a way that isn't surprising or
just broken. Ideas?
>> Unfortunately, there is still one blocker bug that I know of: The unit
>> test for 'container-excursion' is non-deterministic. Once out of every
>> 10 to 20 test runs, it fails, but I can't figure out why. For anyone
>> interested, here are some strace snippets:
>
> Ouch, this one looks more difficult. :-)
Yes, I have no idea what's wrong. Sapping... my... hack... energy...
> I’ll comment on the individual patches.
Much appreciated.
> Thank you for the nice code!
Thanks for sifting through all of this code!
- Dave