Off the top of my head, issues I've seen with systemd:
* At some point there was no way to say, "bring up this service once the network is up". I mean, there was technically a "network" target, but it considered "localhost" as a network. So if, say, you have automounted NFS, the automounter starts running before your main interface has DHCP. This setup been a widely-used configuration for decades; the systemd maintainers didn't care.
* At some point, if you typed "reboot ; exit" in an ssh session, the "reboot" would hard-kill your ssh session and your shell before the "exit" would be run; so your ssh connection would then hang until the machine came up again and refused a TCP resend request.
* The whole thing with systemd reading the kernel's command-line, deciding that "debug" was meant for it, and spamming the logs making it completely unable to boot; and forcing the kernel to introduce a work-around to hide "debug" from systemd.
* The whole interface renaming thing that's happening in Debian now; every time our project has upgraded our test systems from jessie to stretch, and then stretch to buster, we've had to spend dozens of man-hours figuring out why our network configurations aren't working.
The problem here isn't so much that there are these sorts of bugs; the problem is that there seems to be an attitude of, "Well my set-up works; yours doesn't matter." That's not the attitude such a core piece of infrastructure should have.
Compare this to Linus' nearly fanatical insistence that things in userspace should continue to work. If Lennart Pottering had the same attitude towards breaking existing systems that Linus has, systemd would probably be incredibly popular.
I thought the workaround patch was not merged?
(The bug wasn't that systemd generates debug output when the kernel command line contains 'debug"; the bug was something else, which caused systemd to generate an absurd amount of debug output.)
ProTip, the ssh manpage has a great section on "Escape Characters".
By default you can terminate an open ssh-session by typing:
"Enter", "~", then ".".
There are other options, such as adding/listing port-forwarding at run-time and backgrounding your open ssh connection too.
ssh <host> "shutdown -h now ; exit"
[wait for the machine to stop responding to pings]
[wait for the machine to start responding to pings]
[Do the next thing]
With ssh hanging:
* If the shutdown/start again succeeds, then the "wait for it to stop responding to pings" happens after it's rebooted.
* If the boot doesn't succeed, the whole system waits for ssh's timeout (which is quite large) before failing.
EDIT: I should clarify, this issue has been fixed in Debian at least for a while; but I just tripped over it again when I was playing with an Ubuntu VM; maybe 16.04?
And anyway, the network-online.target mechanism always seemed like a hack added to placate the people who insist that it exist rather then fix their software to not couple tightly into the concept of "the" network being "online". ;)
Today (literally) I wanted to launch Xilinx hw_server as a daemon that my peers could restart if it broke itself (it's... prone to doing so). While I could write an init script that knew about PID files, creating a systemd unit was _vastly_ easier.
Yeah, it's not Unix, but UNIX is also sort of terrible for anything that's not a one-shot, no?
Sure, bazaars are nice, but times like this really make me appreciate cathedrals.
runit is one of them, daemontools is another. NB. runit is a daemontools clone that isn't written by Bernstein.
Traditional sh init scripts were able to handle this as most such services could fork and exit once they were ready, but fork and exit is incompatible with daemontools.
Some daemontools clones have ways to handle this, but IIRC daemontools itself does not.
The main selling point seems to to be less complexity. Are there any drawbacks/gotchas one should be aware of?
The vast majority of people are fine with it, it's just the loud minority opposes it.
The bulk of linux userbase is systemd only: Centos, Ubuntu, Arch, Opensuse, Fedora. I think these 5 have already 90+% of installations.
That does not change your point about systemd adoption. Debian has been in practice systemd only for how many years?
And way more than 10% if we consider that Ubuntu is built on Debian.
https://lists.debian.org/debian-devel-announce/2014/08/msg00...
For the record, the TC expects maintainers to continue to support
the multiple available init systems in Debian. That includes
merging reasonable contributions, and not reverting existing
support without a compelling reason.
https://qa.debian.org/popcon-graph.php?packages=systemd%2C+s...
I'd go further and say you definitely can't rely on popcon, for two main reasons:
1 - Not many sysadmins are happy to install a program that "phones home" at regular intervals about system usage.
2 - Popcon records file access times, so a server that runs for long periods between restarts or reboots shows init files are accessed infrequently. This skews the result towards desktop and laptop installations (which are most likely to use the default init).
Exactly. As confirmed by this vote.
Distros adopted systemd because it solves a huge waste of time that distributors have to deal with: maintaining init scripts. systemd unit files are distro-agnostic and can thus be maintained upstream.
(There's also other useless idiosyncrasies that systemd plowed over, so there's even less work for distributors to do. Or rather, more time to do actually interesting work to differentiate their distribution.)
Sure, systemd has it's issues (notably scope creep) but for most use cases it is arguably an improvement.
There is absolutely no technical reason why different worlds cannot coexist, at least in our case.