Re: [PATCH 0/15] Add preliminary support for Linux containers

["Thompson, David" <dthompson2@worcester.edu>]

On Tue, Jul 7, 2015 at 6:28 AM, Ludovic Courtès <ludo@gnu.org> wrote:
> Howdy!
>
> In short, this is awesome!
>
> Here are random notes I took as I was playing with all this.
>
> David Thompson <dthompson2@worcester.edu> 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