On 06/02/14 12:07, Helmut Grohne wrote: > This functionality is entirely orthogonal to the one I was proposing. > You are talking about redirecting the init script invocation to a > running systemd instance. I am talking about sysvinit (as pid 1) to > execute systemd .service descriptions.
I'm sure we've been over this, on this very list, in several previous threads. I used to think this was a great idea, too; I've been convinced that it isn't feasible. Part of the reason that systemd service descriptions are so simple is that there's a significant amount of code in systemd to make them simpler. Any wrapper that executed these descriptions would need to provide the same semantics (or a large subset, and significant effort to debug service descriptions that were only tested with "real systemd" and make them work with "fake systemd"). One example is that because systemd uses cgroups to "capture" all the processes from a service, the service doesn't need to be careful to track all its child, grandchild, etc. processes and make sure they get cleaned up. (Real-world example: gdm3 doesn't currently kill all its child processes on exit, <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=730653>. I suspect that that bug just doesn't happen under systemd - which was probably the only configuration tested upstream - because systemd + cgroups do that work, once, for all services.) Another example is that socket activation and automounting filesystems means that many dependencies can be implicit. (Real-world example: systemd services never need to depend on dbus.service or syslog.service, only on the corresponding sockets, which are part of the default dependency set.) I'm sure there are more bits and pieces like those, that systemd services are free to rely on for (potentially major) simplifications. If you think you can prove me wrong, you're more than welcome to write the tool that does this. I would predict that it will need to be written in C/C++ to get enough control; it will either be Linux-specific or have explicitly separate code paths for Linux and kFreeBSD; by the time it works reliably, it'll look rather similar to systemd; and by the time you've sorted out circular dependencies, it'll have about the same level of coupling between components as systemd. If I'm wrong about that, great; again, please prove me wrong. I'm not going to write that tool, because I already have one; it's called systemd. :-) S -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52f38169.8070...@debian.org
