"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? (The daemon works around that by running processes under a separate UID and doing kill(-1, SIGKILL) under that UID.) Ludo’.