Hi, Ludovic Courtès <l...@gnu.org> writes:
> Maxim Cournoyer <maxim.courno...@gmail.com> skribis: > >> Ludovic Courtès <l...@gnu.org> writes: > > [...] > >>> If I write: >>> >>> (gexp->derivation "foo" #~(mkdir #$output)) >>> >>> I can be sure that my derivation depends on nothing but (default-guile). >>> This is important for tests, but also to make sure we can use this >>> primitive everywhere—if it pulled in the Shepherd, I wouldn’t be able to >>> use to build glibc, because there’d be a cycle. >> >> I was not suggesting to pull in extra dependencies such as Shepherd, but >> to weave the to-be-added signal handling logic at a much lower level. >> One idea could be to arrange so that the correct signal handlers always >> get installed for any Guile code running in the build side (I'm not sure >> how, but perhaps by adjusting the gexp "compiler"?). >> >> The handlers could be defined in (guix build signal-handling) or >> similar. Users wouldn't need to explicitly import the module and >> install its signal handlers, that'd be taken care of automatically, all >> the time. >> >> Does that sound feasible? > > Not like this: the imported-modules derivation for (guix build > signal-handling) would be a dependency in themselves. I see a couple of options for the lowest place to inject the minimal signal handling of a PID. 1. In Guile itself. We could make it detect when it's running as PID 1 and then set up the required signal handling. This is apparently what Bash does, a peculiarity exploited by NixOS (they launch their builder scripts via Bash, which is PID 1 and takes care of reaping the dead processes) 2. In a Guile wrapper. Instead of running Guile directly in the container, guix-daemon would run it through a wrapper that acts as PID 1. This would make it a tool comparable to dumb-init [0] or tini [1], except written in Scheme. [0] https://github.com/Yelp/dumb-init/ [1] https://github.com/krallin/tini If we implement 1, it'd make Guile potentially useful as a wrapper itself to launch scripts in containerized environment (the same as tini), and it alleviates any integration overhead for us, so I find it attractive. What do you think? For further reading, see [2], which I found interesting. [2] https://medium.com/hackernoon/my-process-became-pid-1-and-now-signals-behave-strangely-b05c52cc551c -- Thanks, Maxim