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