|
Top-level
 … with tools such as systemd-run/run0 much of the functionality of systemd-nspawn ended up being available for service management too (such as the pty interactivity), with only some parts remaining that only nspawn could do. So in order to streamline things and simplify our codebase, we figured it might be nicer to eventually merge the two, or more specifically: have a full-blown implementation as part of service management, and then… 3 comments
…the other options, as software run this way must be ready to run as PID 1 (i.e. reap reparented children and so on). Note that in the Docker world the understanding that PID namespacing is semantically much more special than the others is not really commonplace (yeah, thinking about semantics wasn't their strength), hence I guess a lot of software that has been changed to deal with Docker's idiosyncrasies, probably is fine PrivatePIDs=, but I am nonetheless pretty sure PrivatProc=… …is almost always he better way to sandbox regular services than PrivatePIDs=. (PrivateProc= hides processes, but doesn't renumber them or introduce a new PID 1 with its special semantics. PrivatePIDs= does otoh renumbers and does synthesize a new PID 1). Anyway, this is all for today! |
Gregory's Server
…have systemd-nspawn as a full-OS container centric frontend to it.
Hence, with this release we now add PrivatePIDs= which adds the key requirement to run full OS containers as regular system services (without any further container mgr in the mix). There is more work to be done, but one of the most basic/fundamental steps is now done.
PrivatePIDs= should really not be misunderstood as "just another sandboxing" option. Because it really isn't. It's changes semantics a lot more than…