On Sat, Jun 13, 2015 at 4:19 PM, Ludovic Courtès <l...@gnu.org> wrote: > "Thompson, David" <dthomps...@worcester.edu> skribis: > >> On Sat, Jun 13, 2015 at 9:06 AM, Ludovic Courtès <l...@gnu.org> wrote: >>> "Thompson, David" <dthomps...@worcester.edu> skribis: >>> >>>> On Fri, Jun 12, 2015 at 11:12 AM, Ludovic Courtès <l...@gnu.org> wrote: >>>>> "Thompson, David" <dthomps...@worcester.edu> skribis: >>>>> >>>>>> Yeah, our daemon would do the same thing. We could maybe even have a >>>>>> little Guile library that allows one to evaluate arbitrary scheme code >>>>>> from within the container. :) >>>>> >>>>> Actually, something quite easily feasible would be this: >>>>> >>>>> (eval-in-container #~(system* #$evil-program >>>>> #$(local-file "important-data.txt")) >>>>> #:networking? #f) >>>>> >>>>> ... where the container’s store would be populated with just >>>>> EVIL-PROGRAM and the local file. >>>>> >>>>> Food for thought... >>>> >>>> Ooooh yeah! That would be cool. Though I think we should still spawn >>>> a dmd process as PID 1 to deal with reaping zombie processes. We >>>> could generate a single service that runs the gexp script. How does >>>> that sound? >>> >>> Wouldn’t it be enough to have the Guile process that evaluates the >>> expression be PID 1 in the container, as is the case in guix-daemon >>> containers? >> >> Sure, it would work, but my concern is that a long-running process on >> a user's machine could create and orphan tons of child processes and >> nothing would be able to clean them up until the PID namespace is >> garbage collected. > > My understanding was that killing a container’s PID 1 (from the outside) > effectively killed all the processes of that PID name space. Isn’t it > the case?
Yes, that is the case. That triggers the "garbage collection" of that namespace, if you will. My point is that, without a proper PID 1 that can DTRT with orphaned processes, a long running process in a container could potentially create a ton of orphaned child processes with no way for them to be reaped without killing PID 1. I wouldn't be very happy if a program that I was running in a sandbox was polluting the process list. I don't think this is a concern for the build daemon because the build process is a (relatively) short-lived process, but running something like a web browser could go on for days, weeks, etc. > (The daemon works around that by running processes under a separate UID > and doing kill(-1, SIGKILL) under that UID.) So, PID 1 in the build container forks and changes the UID or something? Sorry, I'm a bit lost right now. Thanks for trying to explain. - Dave