On Mon, Oct 21, 2013 at 7:08 AM, Tom Gundersen <t...@jklm.no> wrote: > This is a cool feature. However, it seems to me that adding it to the core > makes much more sense, that way the children can be managed properly by > systemd as real services. What problems do you see with adding this to pid1?
There's no inherent technical barrier, but there are some improvements to make and hurdles to jump. systemd unshares namespaces for every direct child spawned. Processes in a pool should usually share the same network namespace, though, among other resources. systemd core would need to accommodate arrays of other currently singular, per-service data, like PID files and status for each child. Given that each child would run as a "main process" from the daemon's perspective, we'd need to treat it to the same oversight. PID > 1 also comes with its advantages. It's an easier place to prove this idea out in isolation. We can studying accept() as a way to load-balance a set of modern (often event-oriented) daemons, a problem that will be equally interesting in or out of core. Because the socket still gets handed through with a PID > 1 pool manager, there's no substantial overhead to the running daemons, making it a reasonable choice for sustained production use. I'd certainly still to see this in core, eventually. David _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
