The real problem I have with systemd isn't the technology itself, as much as the attitude of the people who run it.
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.
Manually breaking the connection is tolerable-but-annoying for interactive sessions. The place where this caused real problems for me is in my testing setup, where I would have scripts do something like:
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]
...and if it didn't shut down within a certain amount of time, or come back up within a certain amount of time, treat it as a failure.
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?
Maybe replace "ssh" with "timeout 10 ssh"? I assume 10 seconds is long enough for ssh to do its thing and short enough that the machine couldn't have come back up.
It wasn't. systemd fixed its actual bug, which was a real bug that caused it to generate an excessive amount of debug output. With that fixed, there was no further issue and no need for a workaround.
(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.)
well the first point is fixed when using networkd. the problem is/was that many systems used their own network solution, like networkmanager (RedHat) which did not fit well into systemd
But that's a big problem: if the scope of systemd is just to be an init system, its answer to everyone who wants to make their tools work with systemd shouldn't be "just use our loosely associated tools instead".
networkd, NetworkManager, etc. all integrate into the network-online.target in exactly the same way. There is no favouritism for networkd in particular.
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". ;)
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.