systemd & the tightly couple core band vs a world of many inits

My embedded devices use SystemD for socket activation and startup. It works really really great.

And I won't mind systemd's containment functionality on my servers.

For instance, a SIMPLE task like "allow the Java program started by this script to listen on port 80" is not really possible with initscripts. At least my puny brain was not able to cope with all the capability inheritance over UID change crap.

With systemd? It's easy! A few lines in the service file and you're done.

Ditto for filesystem containment and secure /tmp.

With software such as bind ( where you never can be sure that it got shutdown thanks to the rdnc message passing system to close it ), or apache, where I routinely see restart being blocked by some child that only arcane shell can kill, I would be among the first to celebrate systemd and cgroup controled process on the server.

I faced issue with sympa not starting and blocking on wait because it needed postgresql to be started first. We see issues with some daemons starting faster than the network card ( cause network service say "ok, i am ok", while it is not, Mandriva used to have a service "network-up" just for that ).

The way we set limit on file descriptor or anything is dependent on the initscript, the distribution, and usually hard to automate. With systemd, that's just .ini, in well defined location with the same and guaranteed semantics, something that is much easier to automate and to deploy.

The old approach was fragile and, stuff like "having 3 openvpn" was done by cut and paste of the initscripts, that's not really ideal IMHO. There is lots of duplicated code in all initscripts from distribution, and that's not how I envision long term maintainance. Gentoo init system was a fresh approach on that point, kudos to them, and systemd push that further.

I cannot comment on embedded device, but for a server, I see the values, even if I understand that some people feel the sysv init way to be fine for them.