> The problem is that when I have 10 or 20 units with interlocking dependencies, it's an absolute nightmare to try and untangle because I have to jump between so many different files
How that's different from sysvinit?
> The longstanding /var/log/messages is now replaced by journalctl tool, and the logs are actually in binary.
`journalctl` prints plain text on its stdout, so you can think of it as a glorified `cat` if you don't want to use its extra features. On the contrary, if one needs its extra features on plain text log files one usually resolves to using fragile parsing hacks.
> The venerable "hostname" command is now "hostnamectl" because it must go through systemd
They do different things, `hostname` only reads the current hostname. `hostnamectl` is able to set the hostname, standardizing what used to be a per-distribution custom mechanism. Despite being shipped with systemd (to make sure everyone can rely on it) it doesn't actually depend on systemd and in no way goes through it.
> They have also replaced chroot with systemd-nspawn, and made it so you cannot even use systemd while in a normal chroot.
`chroot`'s purpose has never been the ability to run an init system inside it, no matter if it is sysvinit or systemd. On the other hand `systemd-nspawn` creates isolated containers, I'd be surprised you can't run sysvinit inside it.
Again, you're comparing apples to whole orange trees as the systemd utilities do much more than the traditional ones you mentioned.
In sysv I can just make a list of startup tasks. A -> B -> C -> D. Easy. 10 things that must start in specific order? No problem, 10 things in list. There is no easy way to do this in systemd. 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). When those dependencies change, I have to go look through a whole bunch of files or look at a graph tool to figure out what is even going on.
> They do different things, `hostname` only reads the current hostname.
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."
> chroot`'s purpose has never been the ability to run an init system inside it
That's fine, but it worked under sysv and now it doesn't. When upgrading or working with different install roots, using chroot is common. Now I can't modify services during that time, unless I migrate everything over to use nspawn.
> the systemd utilities do much more than the traditional ones you mentioned
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.
And in the end you hit a sore point square on the head.
Systemd is not built for traditional server farms, it was initially built to scratch a desktop bootup itch that Poettering (and perhaps Sievers) had that then got extended to deal with booting containers.
To them, and others working on systemd, the traditional server way is history and they are building for the containerized present/future.
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)
How that's different from sysvinit?
> The longstanding /var/log/messages is now replaced by journalctl tool, and the logs are actually in binary.
`journalctl` prints plain text on its stdout, so you can think of it as a glorified `cat` if you don't want to use its extra features. On the contrary, if one needs its extra features on plain text log files one usually resolves to using fragile parsing hacks.
> The venerable "hostname" command is now "hostnamectl" because it must go through systemd
They do different things, `hostname` only reads the current hostname. `hostnamectl` is able to set the hostname, standardizing what used to be a per-distribution custom mechanism. Despite being shipped with systemd (to make sure everyone can rely on it) it doesn't actually depend on systemd and in no way goes through it.
> They have also replaced chroot with systemd-nspawn, and made it so you cannot even use systemd while in a normal chroot.
`chroot`'s purpose has never been the ability to run an init system inside it, no matter if it is sysvinit or systemd. On the other hand `systemd-nspawn` creates isolated containers, I'd be surprised you can't run sysvinit inside it.
Again, you're comparing apples to whole orange trees as the systemd utilities do much more than the traditional ones you mentioned.