> A -> B -> C -> D. Easy.

Oh, sure, sequentially starting up a fixed list of services is probably easier with sysvinit, given that's the only thing it does.

With systemd you probably want to set Requires=foo and After=foo in bar.service to have foo running before bar. It does not seem overly complex, or you meant something else?

> I must create 10 different unit files, and then create a bunch of different dependencies (A depends on B and C, B depends only on D, can C then start at same time as D?, etc).

Wouldn't you create 10 different init script for sysvinit, each with its own LSB header listing the dependencies such that tools like Debian's insserv could correctly schedule them?

I'm quite sure that it's far easier to express complex dependencies with systemd than with sysvinit, if that's your concern.

Correct me if I'm wrong, your dependencies could be handled like the following:

[A]
Requires=B
Requires=C

[B]
Requires=D

If A needs B to be running before A even starts (ie. they cannot be run in parallel) just add After=B to A. With sysvinit I'm not sure if there's a way to say that A needs B but that they can be started in parallel.

I don't get your question "can C then start at same time as D": if they do not depend on each other, I don't see the problem. If they have a dependency, just add After= to the one that needs to be launched later in the process. If you don't know, add After=C to D and you've got a slightly slower but sequential boot as with sysvinit.

> That's... not true. From the first line of the hostname manpage: "Hostname is used to display the system's DNS name, and to display or set its hostname or NIS domain name."

Oh, indeed, sorry. I then guess `hostnamectl` only provides notifications and some extra info on top what `hostname` already does.

> If I lived in a blue sky world, where I was fresh installing one new server with a simple set of services that I had built in systemd, I think I be quite happy with it. The problem is that I have thousands of servers, and a decade or more of accumulated infrastructure that relies on those traditional tools. Then systemd comes barging in and breaks a bunch of stuff, and that is frustrating. I'm not saying I hate systemd, in fact I agree that many of the new tools are quite nice. But it's kind of like the loud hipster that shows up at your party and starts talking shit about the music you are playing, and making fun of your choice in beer. Maybe my music does suck, and maybe these clothes aren't cool anymore, but we were sitting around having a fine time until he came around.

I totally understand your concerns. I guess you don't have many options: you can stick with sysvinit for a while (eg. Debian still officially has full support for it) and in the meantime start making sure your scripts run fine with the LSB compatibility support in systemd (if you're just starting services they should work transparently with no effort).

But consider that in any case, staying with sysvinit has never been an option: during the Debian debate, the contenders for the default were systemd and Upstart, sysvinit has always been kept only as the baseline to test compatibility.

With that in mind, the LSB support in Upstart (and in every other contender) is far less mature than the one in systemd. As the incredibly smooth migration done by the Debian systemd team proves, systemd has the best compatibility support of the pack.

(I mention Debian as that's what I use and for the fact that the systemd maintainers poured a big deal of effort to provide the best systemd/sysvinit compatibility)