When it comes to the shutdown issue, I'd argue this is a side-effect of systemd bringing some consistency and correctness to what used to be the wild west, and is highlighting some issue that was before overlooked.
Granted, in a lot of cases the issue probably wasn't a big deal (the system is being shut down, the user is already logged out, do you really care that a system background process is being shut down cleanly?) but from systemd's perspective there's no difference between that and an actually business-critical process that should absolutely be allowed to terminate cleanly before unmounting the filesystem and powering off the machine.
I agree that systemd gets way more hate than it deserves, but it has continual problems on Arch Linux. Wherever you try to shutdown without logging out first, systemd says ”a stop job is running for user manager...", then waits 90 seconds. The issue keeps getting fixed, then resurfacing. People with this same problem are all over the internet.
Systemd is incredibly controversial among a niche group of people who have strong opinions about how init & core system functionality should work, and then there’s an outer ring of people who focus on one or two problems with some relatively minor problems that Systemd caused for which there are viable workarounds. Like how Systemd terminates processes that belong to your session when you log out.
I remember writing SysV style init scripts or rc.d / BSD style init scripts. It was awful. You had all these copy-pasted shell scripts with various gaps in functionality depending on who wrote them. Getting a service to run in Systemd feels like heaven by comparison. I don’t even care about, like, Docker.
I think the reports of problems (like background processes getting termed on logout, how any security problems in Systemd tends to be severe by nature) were just so numerous compared to the reports of the benefits (like the boot time improvements and the massive improvements running daemons). It was some bad decisions and a lot of bad PR, but the overall impact IMO is very positive.
I also didn't understand the hate for systemd until I have attempted to use it for the first time !
This was a few years ago, so it is very likely that the particular bug that annoyed me was solved since then. Nevertheless, the bug was so unbelievably stupid and it was not only just a coding error but also a problem caused by the wrong architecture of systemd, so I could not accept that it is possible to trust software developers that can make such mistakes.
After that bad experience, I have never touched systemd again.
Even if this was several years ago, systemd had already been in use for several years, so the bug could not be excused by systemd being experimental or something like that.
I use mostly Gentoo Linux, which fortunately does not use systemd, so I had been shielded from its problems. I had heard about some systemd-related controversies, but I had paid no attention to them. I had seen some systemd presentations, which seemed reasonable enough.
One day I was in a hurry, but I had to install Linux on a new computer. Gentoo is nice, but if you do not have a pre-prepared customized installation image, so that you have to install it from scratch, it may need a few hours for compiling everything from sources and for editing the configuration.
So I decided to install Arch Linux, which used systemd. The installation was fast and everything seemed to work OK.
Systemd was always praised for its supposedly fast boot times, but I have seen no improvement in that, compared to my carefully configured Gentoo systems. On the other hand, the computer with systemd was the first computer that I have ever encountered, among many thousands of computers, from the days of Intel 8080 and until the new Zen 3, which was slow at shutdown.
So while the boot time of systemd was OK, the shutdown time was very long, sometimes more than a minute. What is much worse, sometimes the shutdown failed, which is something that I have never experienced before or after. This was on an Intel NUC with a Skylake CPU, so it was not some esoteric, non-standard hardware.
The shutdown failed sometimes due to a race condition, because the systemd daemons exchanged some messages between themselves through dbus, and, IIRC, sometimes it happened that some daemon died before the sender expected and the sender remained stuck in attempts to send to a non-existing recipient, or maybe the dbus daemon died, so there no longer was who to relay the message.
Race conditions may happen in concurrent programming, but to have a shutdown procedure whose success depends on the success of inter-process communication, that shows that everything was ill-conceived at the highest level.
So then I said farewell to systemd, I wiped Arch and I installed Gentoo, which worked perfectly on that hardware, without systemd, but with its much simpler and more reliable openrc.
i think the source of the hate is how little the dialog actually tells the user. imagine the message saying something like "{{ process_name || process_command }} is blocking the shutdown, press F7 to terminate it forcefully"
i doubt anyone would complain about systemd with such a message. its just beyond annoying not being able to see which application is causing the issue nor having any options beyond waiting or removing the power entirely
Back in 2016, systemd started killing user processes on logout (rather than send them the SIGHUP signal, as POSIX says should happen). This caused problems for programs like nohup, screen and tmux, which deliberately keep running. Systemd's response was to say that they should incorporate systemd's library, and use systemd's new daemonization API. As far as I know, none of them did.
Two years later, you can find hundreds of support requests across the internet, from frustrated users who are having their sessions killed by systemd.
Bugs are annoying, but that's life. On the other hand, when you're an impacted user who's lost work, and researching the bug leads you to a years-old discussion in which someone is actively denying that the bug exists and refusing to fix it, that's infuriating. I don't think systemd's developers deserve the trust that maintaining a core piece of infrastructure requires; they don't seem to care enough about whether they've broken things.
That's what I'm describing as a reaction at the time even if it didn't turn out to be a big deal.
I'm a long time Linux guy and when I heard about systemd, the first thing it made me think of offhand was the Windows Registry. Now I'm not super-deep on that level of Linux but I could understand the knee-jerk reaction at the time. But you're correct technically, and I think time has proven that there's not much of an issue.
My personal/corporate, n=~500 experience is that it boots faster, shuts down slower (technically because it is doing it "properly"), and if you have any problem during shutdown it is absolute PITA to debug why.
We did managed to throw away few thousand lines of code of fixed init scripts after moving to systemd and get rid of few other stuff so it has been positive but definitely some of the bad with a lot of good. Journald logging format is also kinda fucked that causes some nasty edge cases
Except of systemd-resolved, this utterly radioactive piece of shit can go fuck itself.
People are probably less upset because it doesn't take the "systemd all the things" approach of getting rid of huge chunks of old stuff for what is ostensibly an init system. I don't have much of an issue with systemd (except binary logging; I hate that) and just put up with it, but the reasons for which people objected to systemd don't seem to extend to this.
I'm an old school unixhead who's nonetheless made his peace with systemd because, honestly, it makes lots of things work way better than most previously available solutions did.
Thing is, it also forcibly changed a bunch of things by introducing defaults that were not at all what people expected. They might have been better overall, but it still caused some nasty surprises.
Let me try and explain a bit more concretely -
An easy example (not a hypothetical one, btw): if you have a physical server with multiple hard drives and one of them doesn't start, old school unix would boot everything it -could- boot anyway. SystemD changed that behaviour to "if a filesystem doesn't come up, and you don't set an option to tell systemd it's ok if that doesn't happen, don't finish booting".
Now, imagine you're somebody who has a physical server somewhere that has a big cache disk that you use a cheap drive for because if it fails, well, you've lost some cache space. Now imagine your server used to run a pre-systemd setup, and when you upgraded it to a systemd using version of the same distro you left all your settings as-is because everything seemed to be working fine. Now ... imagine that drive dies during a reboot ... and so the server doesn't finish booting, and so you can't even ssh in to it to figure out what's going on, and the only way to figure it out is to get physically in front of the console.
If that server is four hours' drive away, you might not be very impressed.
I still, overall, think systemd is pretty nice. But while some of the people annoyed with it are annoyed with it on a purely aesthetic/principle sort of basis, there are definitely some decisions the authors made that caused -very- surprising results for people who had been running servers for years already, and some of the dislike being thrown around is very much understandable.
That might be true and still not contradict what I said. A lot of the systemd critics still seem to not see what it actually did for most people using it. You're free to hate it and some of that is certainly justified, but don't assume that the contrary opinion is based on uneducated or misguided opinions.
Most of what I see/use of systemd I like. Some of it I don't, and some of it is a dumpsterfire. I think I could say the same or worse for any ambitious software project.
As for the security issues I certainly place those in the dumpsterfire category and I'd like for the systemd team to handle them better.
I've been generally OK with systemd, and think most of the complaints about it were over-dramatic, but this is exactly one of the things we were warned about, right?
It's a reasonable counterpoint, but limited to the part of systemd that manages starting and stopping services.
It also takes over virtual terminals, syslog services, login management, network interface configuration, dhcp, system time, udev device management, containers (machined, dbus, cgroups).
I'm not arguing against your ability to pick something else.
What I see, however, in most of the opposition to systemd is that most who criticise it don't understand these design considerations and often aren't even aware of the problems involved.
This is why they keep coming up. If most people designed systems that took care of these things in other ways, it wouldn't be so much of an issue. But most people don't. E.g. the fact that most Linux distros for the longest time kept running critical system services straight from init scripts with no process manager or other restart logic is a good example.
As a sometimes-administrator of Linux systems, I have lots of reasons for finding setting up, altering, and reasoning about various daemons to be all much better and less error-prone in a systemd world.
It also seems a bit of a straw man to still be making the pro-systemd side as if it's mostly about boot times. I also barely ever reboot my system but still appreciate systemd's approaches to things like logging, service status, and service overridability.
I recently put together a systemd system, here's a list of grievances compared to the previous setup:
On boot, systems waits for two minutes or so for dhcp on an Ethernet interface with no cable, and it's not cancelable if I happen to be at the console
On shutdown, it turns off swap before shutting down daemons; not an issue for my system because I don't expect swapping, but in what world does this make sense?
Closing the lid sleeps the computer without configuration; some people might find this to be a good thing, but in my experience in the last 15 years, Linux only slept on lid closure if i was running software to handle that (acpid and/or something from a desktop environment), if i have apache running on an old laptop with no GUI, i expect it to stay on. (yes, there's a config, but its still annoying)
My basic dislike for systemd is it a large change to the overall system, and doesn't provide me any benefits that I can tell. Beyond that, I've experienced or read about many negative things.
a) I ran into an issue with changes in startup scripts in Debian which meant I could no longer hit ctrl-c to stop network initialization on a laptop when it couldn't get a dhcp lease (it was either not connecting well to wifi , or trying to get a lease on a disconnected wired NIC; it was a while ago, I don't quite remember)
b) there have been many secuirty issues in systemd and systemd-* utilities. Quite a few of which were repeats of issues existing daemons had been through, that shouldn't have been repeated.
c) I have read that in default configurations a user's programs will be terminated after the user logs out; that's not acceptable for me, and a large change in default behavior
For me, systemd is yet another churny subsystem that drives aggrivation, so since I was already exposed to FreeBSD through work, it made sense to me to go in that direction at home, instead of sticking with Debian and accepting systemd.
It's funny that in the case of systemd both the scenario and hence also the complaints were the complete opposite. Namely that systemd does everything, that in an idealistic world should have been decoupled from the core. (Which was also FUD since the internals actually are decoupled and work alone).
Granted, in a lot of cases the issue probably wasn't a big deal (the system is being shut down, the user is already logged out, do you really care that a system background process is being shut down cleanly?) but from systemd's perspective there's no difference between that and an actually business-critical process that should absolutely be allowed to terminate cleanly before unmounting the filesystem and powering off the machine.
reply