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
