About a year ago, we started switching over new servers to systemd instead of openrc at work. I knew sysv/openrc/bsdinit and I liked them so for the first month or two I utterly despised systemd. (Plus as a sysadmin it seems like I have to hate it or risk losing my linux card) I just wanted my damn scripts back instead of dealing with the .ini-inspired config file crap. If I had a choice at the time, I would've been willing to move to busybox-init just to get away from systemd. Had I spent less time complaining to my coworkers about how much it sucked, I probably would've written this post myself. But little by little it grew on me.
Oh, so if an nfs mount fails on boot, it's not going to just sit there and hang? I guess that's pretty cool, saves me from having to throw a console on it while muttering under my breath. And it didn't start nginx either, so it's not going to serve a half broken site and tell the loadbalancer all is good? Maybe it's not all that bad. No no, what am I thinking, this is still crap, I could've written all this in to the init scripts (but I didn't).
This client's service is irritatingly unreliable, maybe I should write a wrapper to supervise it. Someone must have done something like this for syst... Restart=OnFailure... well that's nifty.
Ugh, monitoring daemon ate up all the memory again, why can't the vendor get their shit together or the client switch to something that isn't useless. Guess I'll google some ideas for a watchdog script. Hmm, looks like I can just throw MemoryLimit and Restart=onfailure in the unit? No way it's that easy. (it was)
After a couple months of this, systemd actually started to seem useful, I even started having a little bit of dread when hopping on an older server and having to deal with openrc. All of the complaints here really seem off base to me now that I've had a chunk of time to figure it out. Init scripts pissed me off when I didn't have much experience with them too. Now, thats not to say I like everything about the systemd switch. netctl is utterly worthless for anything other than a static ipv4 address (and reenable, really?). I still forward all my logs to syslog, because I prefer text files (and all the awk/sed/grep/cut/sort/column/etc goodness that comes with them) for anything more than running `systemctl status <service>` and seeing that I accidentally the config file for something.
I also don't buy the whole "It should be on desktops, not servers" because I don't see much of an advantage for desktops, other than maybe the trivially faster boots. Wifi is a pain in the ass with netctl and netctl doesn't seem play well with anything else. But for servers, I've found it to be pretty awesome.
To address a few things straight from the article that I disagree with:
>At least one Debian package (memcached) is already invoking a wrapper script from ExecStart.
This is exactly why I don't understand the whole argument around it being inflexible. If you need to call a script that does some setup that's incompatible with systemd, call the script? It's no different from helper scripts that many packages used with init scripts. If you still want to do some checks and call start-stop-daemon, go right ahead, nothing is stopping you. It seems pretty strange to consider it a fault that you can't use a bash script, and then complain that you'll have to use a bash script.
>Here, let me helpfully tell you that you should run systemctl daemon-reload, but perform the action you requested using the old configuration anyway.
This really seems like a trivial complaint. I guess you could always alias systemctl="systemctl daemon-reload; systemctl" if it's that much of an issue. Personally it's saved me after an accidental :wq (damn that muscle memory). "File has changed on disk" uhhh it shouldn't have. crap. I guess it's a matter of preference. Also I didn't even know systemctl edit was a thing. That does seem kinda pointless, but it also seems kinda pointless to be bent out of shape over it. Do you also cat `* * * * * command >> /var/spool/cron/crontabs/$USER` because crontab -e is babysitting you? (I used to do that, but because e and r are too close together and reconstructing a crontab from logs is painful. Now I just alias crontab="crontab -l; crontab")
>Now, systemd does rely heavily on D-Bus
I've never run into issues with it, but I do agree with you on that point from a philosophical standpoint.
>And yes, you can avoid the whole issue just by masking any units you don't want to start, but that's missing the point.
The only point I see is that it's different. Of course whatever you're used to is going to be more effecient to you than something new.
>I believe it creates more problems than it solves. Sadly, many of those problems will take years to become apparent, by which time all the major Linux distributions will have fully integrated it.
Well it definitely seems to solve more problems for me than it creates, and saying those problems will only be apparent years down the road is not only impossible to argue against, it's a hand wavy cop out of "Trust me, its just bad! Because reasons!" However this does touch on what is probably my biggest gripe with systemd, and that is that ALL the big distros seem to be switching. Granted I don't mind from a having-to-use-it angle, since I personally prefer it and would probably stick with distros that do anyways, but it does give me a certain unease, it may be my choice but it shouldn't be the only one, and I'd have the same problem if it was sysv that everyone switched to.
All in all, these complaints really just seem like complaining that it's different. And it is different, but that doesn't necessarily make it better or worse, just takes time to get used to.
You either must have gotten in late, or been exceedingly lucky, as failing NFS mounts is one of those things systemd downright hates.
People have had whole boxes fail to come up because of a NFS mount that didn't work, and therefore the unit file didn't come up roses, and so systemd decided to abandon ship and present the admin with a borked minimal console.
One early fix, a brute force 30 second kill timer on every unit file.
Went over well with one Fedora Alpha (lucky for them) where said timer tripped on the post distro upgrade house cleaning unit.
Oh, so if an nfs mount fails on boot, it's not going to just sit there and hang? I guess that's pretty cool, saves me from having to throw a console on it while muttering under my breath. And it didn't start nginx either, so it's not going to serve a half broken site and tell the loadbalancer all is good? Maybe it's not all that bad. No no, what am I thinking, this is still crap, I could've written all this in to the init scripts (but I didn't).
This client's service is irritatingly unreliable, maybe I should write a wrapper to supervise it. Someone must have done something like this for syst... Restart=OnFailure... well that's nifty.
Ugh, monitoring daemon ate up all the memory again, why can't the vendor get their shit together or the client switch to something that isn't useless. Guess I'll google some ideas for a watchdog script. Hmm, looks like I can just throw MemoryLimit and Restart=onfailure in the unit? No way it's that easy. (it was)
After a couple months of this, systemd actually started to seem useful, I even started having a little bit of dread when hopping on an older server and having to deal with openrc. All of the complaints here really seem off base to me now that I've had a chunk of time to figure it out. Init scripts pissed me off when I didn't have much experience with them too. Now, thats not to say I like everything about the systemd switch. netctl is utterly worthless for anything other than a static ipv4 address (and reenable, really?). I still forward all my logs to syslog, because I prefer text files (and all the awk/sed/grep/cut/sort/column/etc goodness that comes with them) for anything more than running `systemctl status <service>` and seeing that I accidentally the config file for something.
I also don't buy the whole "It should be on desktops, not servers" because I don't see much of an advantage for desktops, other than maybe the trivially faster boots. Wifi is a pain in the ass with netctl and netctl doesn't seem play well with anything else. But for servers, I've found it to be pretty awesome.
To address a few things straight from the article that I disagree with:
>At least one Debian package (memcached) is already invoking a wrapper script from ExecStart.
This is exactly why I don't understand the whole argument around it being inflexible. If you need to call a script that does some setup that's incompatible with systemd, call the script? It's no different from helper scripts that many packages used with init scripts. If you still want to do some checks and call start-stop-daemon, go right ahead, nothing is stopping you. It seems pretty strange to consider it a fault that you can't use a bash script, and then complain that you'll have to use a bash script.
>Here, let me helpfully tell you that you should run systemctl daemon-reload, but perform the action you requested using the old configuration anyway.
This really seems like a trivial complaint. I guess you could always alias systemctl="systemctl daemon-reload; systemctl" if it's that much of an issue. Personally it's saved me after an accidental :wq (damn that muscle memory). "File has changed on disk" uhhh it shouldn't have. crap. I guess it's a matter of preference. Also I didn't even know systemctl edit was a thing. That does seem kinda pointless, but it also seems kinda pointless to be bent out of shape over it. Do you also cat `* * * * * command >> /var/spool/cron/crontabs/$USER` because crontab -e is babysitting you? (I used to do that, but because e and r are too close together and reconstructing a crontab from logs is painful. Now I just alias crontab="crontab -l; crontab")
>Now, systemd does rely heavily on D-Bus
I've never run into issues with it, but I do agree with you on that point from a philosophical standpoint.
>And yes, you can avoid the whole issue just by masking any units you don't want to start, but that's missing the point.
The only point I see is that it's different. Of course whatever you're used to is going to be more effecient to you than something new.
>I believe it creates more problems than it solves. Sadly, many of those problems will take years to become apparent, by which time all the major Linux distributions will have fully integrated it.
Well it definitely seems to solve more problems for me than it creates, and saying those problems will only be apparent years down the road is not only impossible to argue against, it's a hand wavy cop out of "Trust me, its just bad! Because reasons!" However this does touch on what is probably my biggest gripe with systemd, and that is that ALL the big distros seem to be switching. Granted I don't mind from a having-to-use-it angle, since I personally prefer it and would probably stick with distros that do anyways, but it does give me a certain unease, it may be my choice but it shouldn't be the only one, and I'd have the same problem if it was sysv that everyone switched to.
All in all, these complaints really just seem like complaining that it's different. And it is different, but that doesn't necessarily make it better or worse, just takes time to get used to.