Re: Two line init.d scripts? Sure, that will work!
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
Reply to: