- Binary Logs: Sorry, but there is no advantage to not being able to easily look at a log file.
Technically, there is an easy way to look at the logs, it just requires a utility that is not cat or grep. But I get your meaning. Binary logs are certainly not my preference, but for tools that need to interact with and parse the logs, it is a necessity. There are ways to get your text logs back, though, and some distributions configure it this way by default.
...which will almost certainly break if the logs get corrupted at all. The great thing about text logs is that my brain can figure out what values are probably garbage and which ones are the remnants of the (now corrupt) log a lot better than a computer can. There are certainly ways of hardening binary logs, but why? syslog is a PITA to parse by machine not because it's text-only, but because the formatting is from the 1960's. I'm not arguing it has to be syslog format, just text.
- Failure to Log to the Console:
It is in the log.
...until you don't GET the log because it wasn't *WRITTEN*, which probably hasn't happened to you because you're probably booting a fairly standard configuration. But it took me 3 f'ing hours to debug the fact that my permissions were wrong on my NFS server when I was net-booting because I got no shell and no log (because the permissions were wrong). That would've take 20 seconds with logging to the console and knowing more about systemd wouldn't have fixed that.
- Failure to Drop to a Shell When It Breaks:
Once again, it is in the log. I'm not sure why being dropped to a busybox shell gives you a much better way to debug than just reading the log messages. If you want to test individual systemd services, you can do that with systemctl start/stop/etc.
Because sometimes it's a lot nicer to try to reproduce the failure right then and not have to reboot the system in order to get to the log. Remember, no shell means you can't read the log *at all* without rebooting.
However, if you use that command as root, it tells you not to run it as root. If you do it as a normal user, it doesn't have permission to read all the files to tell you what it's doing.
If that is true, it is a bug.
Maybe, but systemd --test --system prints "Don't run test mode as root" on OpenSuSE 12.3 and Fedora 20.... While trying a few other distro's to post this comment, I ran across "systemd-analyze --order --system plot" (which wasn't in the original distro that I was debugging, but it was ARM so maybe it was weird) which appears to be able to generate a graph in SVG, which, while huge, appears to help me a lot.
- Races: I no longer have any idea what order things are starting in.
If a dependency issue is causing your boot to randomly fail, then your systemd configuration is horribly broken. ... You don't know what order services are starting in because you shouldn't need to. The only thing your unit should do is specify a preferred ordering. ..
...until something doesn't work. Yeah, the config I've got *IS* horribly broken. I'd like there to be some reasonable way for me to figure out how to fix it. And sometimes I don't *PREFER* an order, sometimes I *REQUIRE* an order. On my desktop? Couldn't care less because it "Just Works(tm)' and I rarely change the distribution's defaults. On my servers, it's more complex. Maybe "prefer" in this case means it will always honor that?
Have you every really had to deal with the complexities of the sysV init system? It is not pretty. "Jiggling the cord" until it works is about all you can reasonably do with sysV when you have a complex init.
Yes. I obviously have no idea what your experience is, and maybe you had a horrible one with SysV. I've had my share of battles with it and I'd never argue it's perfect, but it's a lot easier to debug than systemd. When everything starts in serial order....
It doesn't "mount filesystems" at a single time during boot the way sysV does. You can move service files to other filesystems, but then you need to tell the service config that you did this so that it can bring up that filesystem before starting the service. This is actually a lot easier to do with systemd than with sysV.
In SysV, almost *nothing* happened before filesystems, so I rarely had to touch *anything* in /etc other than /etc/fstab when things moved. Now, I've gotta touch the config files for every service I move, which is easy if I wrote the service, but not so easy if I didn't and maybe don't even know what it's called. Why is this easier? I'm terrified of what's going to happen when I move a few subdirectories of /var to a different filesystem on a cluster, but I'm going to find out next week. I'm hoping to be pleasantly surprised....
Well, this is more of a rant than a series of legitimate complaints. You can't expect the systemd people to understand your issues if you haven't even taken the time to learn how systemd works first.
Yeah, it *IS* a rant. But that doesn't mean that the stuff I'm complaining about isn't a real problem. I've always hated the "let's make it complicated and blame the user if they can't figure it out" philosophy. I will waste hours figuring it out. Why is this a waste? Because in the end, I've gained *no* capability that I didn't already have except faster boots and since I boot my servers less than once a month, that gains me nothing. It's awesome that Linux is gaining share on the desktop. udev, for all its warts, was *sorely* needed since I don't wanna run "mkdev" every time I plug a USB device (etc). However, until systemd, the changes for the desktop played nicely (and in most cases added capability) to the server use cases. systemd just doesn't.
Oh, I knew I'd think of something else. systemd even managed to break shutdown on a netboot'd system since, apparently, it's weird set of dependencies don't check to see if the root filesystem is mounted over the network before shutting down the network.... Again, obviously distribution dependent, so if you know of one that can actually deal correctly with an NFS root, let me know...