As I told Jesse on IRC, the patch isn't going in. I'm not including
OS-specific code into s6, even with a compile-time option. The main
reason for it is that it changes the API: the choice to spawn the
service in a new namespace or not should be made at run time, so
it would introduce a new file in the service directory that would only
be valid under Linux, and the file would need to be supported by
s6-rc and friends even on other systems, etc. This is exactly the kind
of complexity created by OS divergences that plagues the Unix world
and that I very much want to avoid. This change itself looks quite
simple, but it would be a precedent and the slope is extremely slippery.
>Though as Jesse explained, this requires some sort of exit/signal
>proxing, which isn't the case here. Here the direct child of
>s6-supervise remains the daemon itself - in its own pid ns - which is
>much better.
It would unarguably be more elegant, yes, but since there's a way to
do without it, it's only about elegance, not feasability - and I really
think the cost for elegance is too high.
execline's 'trap' binary can adequately perform the needed proxying at
low resource cost.
If more various namespace feature requests come in, at some point I
will look for a way to integrate some namespace functions into skalibs,
with proper compile-time guards and stubs, and then reconsider; but as
long as there are ways to achieve the desired outcome with external
tools, it's not a priority.
--
Laurent
Received on Sun Jul 16 2017 - 08:41:03 UTC