I get that not everybody likes systemd, but a lot of the criticisms seem misguided and looking at sysvinit with role-colored glasses.
For example, people are complaining about logind being included, but forget that consolekit was unmaintained before that. Yes, there's parts to systemd that not everyone will use, like container support, but in that case you can pretty safely ignore that use case.
For me, systemd has provided a much more consistent way of managing services. There's a tightly defined service definition format that allows one to comfortably modify any 3rd party service as well, (unlike random, variable-quality shell scripts), relatively small amount of commands to learn that work consistently across services, mounts, timers etc. There's also much better handling of modern hardware, hotplugging & the like.
I can't say I miss sysvinit. Also, stuff like [1] from the anti-systemd camp doesn't inspire confidence.
I read everything I could find on systemd to form my own opinion. I used FreeBSD for a decade and have many years of Ubuntu/upstart experience after that.
Based on my experience and all the anti-systemd posts online, I expected to dislike it.
But on it's merits I really like the consistency it brings to the "system layer" of the OS.
I find it's shame when developers skip over systemd for consideration, adding extra layers of complexity when systemd alone would have been sufficient: For example, using Docker when the basic isolation features of systemd would do, or using "forever.js" to manage Node.js processes, when systemd could could be saving 15% memory overhead per process, using software already installed in the base system.
On the other hand, I do support diversity of software and am glad to see some other options still being promoted and used. The dangers and weaknesses of monoculture in the physical world apply to software systems as well.
One of my biggest issues with systemd is that I don't like the idea of not being able to replace pieces of it. If I don't like their logging, dns, or ntp daemons, I can't easily replace them without feeling like a second-class citizen and/or having the overhead you've mentioned.
From my understanding, alternatives _could_ be written, but haven't yet and that means we currently having to ignore more battle-hardened software in favour of whatever is in systemd by default.
"systemd is, to put it mildly, controversial. Depending on who you ask it's either a complete violation of the UNIX philosophy, a bloated pile of bugs, a complete violation of the elegant simplicity it replaced or, it most cases, some or all of the above. So why have so many Linux distributions taken to it? Is it as bad as people say?
I watched this a few weeks ago as well, and it is a very good, even-handed overview of systemd. He talks about the history and other tools that came before, like Apple's `launchd` and Ubuntu's `upstart`. He also talks about the actual problems with it, rather than the FUD hysteria (and also explains why some of them are FUD).
He's from the BSD world, so his POV is as an (mostly) outsider.
I love this video and have to share it every time I see this debate. He really show how this argument is kind of weak and this is coming from a BSD guy!
That said, to me systemd has been a large improvement. Maybe it has its problems, but at least there is consistency in handling services and logs between Linux distributions, which is a big improvement over a bunch of homegrown sysvinit derivatives, Upstart, and homegrown non-sysvinit scripts.
I mainly use FreeBSD, but I have a number of Linux VMs that I use where appropriate.
The big thing, for me, that systemd brings to the table is consistency. Managing services on CentOS is the same as managing them on Debian which is the same as managing them on OpenSUSE. This makes it a lot easier to deal with the various different Linuxes.
Also, it seems to make writing a service a lot easier. Instead of the service needing to daemonize, write out a PID file, or whatever, it can just be a program that does its thing without forking, sends its output to stdout/stderr and systemd takes care of the details. I tried to go through this exercise on a FreeBSD system and ended up just installing 'pm2' to do it for me. I subsequently figured out what I did wrong, but pm2 is working and I see no need to change it.
Obviously systemd isn't suited for every use-case, but it doesn't seem nearly as bad as some people make it out to be.
I actually really like systemd's service files, and the functionality it provides. I like the ability to express dependencies clearly, the fine-grained control over server restart behavior, and a ton of other systemd features. I'm also very happy to see it replace cron.
What I _do not_ like are:
- systemd-resolved
- systemd-networkd
- systemd taking over disk mounts
- systemctl
- unit files spread out all over the place
- mandatory journald
- mandatory dbus
- only works on Linux
- pushing the BSDs farther towards being obsolete
I'm very glad to see sysv-init on the way out, personally. I think systemd unit files are a huge improvement, and greatly improve standardization and init quality. But that doesn't intrinsically mean that the systemd project is doing the right thing.
It's comical how people get so "jazzed" about something like not liking systemd and make a whole movement about it (with their t-shirts and everything). I get people may not love everything about systemd (or maybe they hate it), but I'm not convinced it's so bad. I've been using it since RHEL 7 and I've really gotten used to all of the benefits of systemd. It also doesn't hurt that I went to the session on pid 1 by Lennart Poettering at Red Hat Summit 2014 and he convinced me of the at least not-horribleness of systemd.
The simple reason is that everybody is forced to deal with it. So you either like the way it works, or you dislike it, but there's no real option to just ignore it in Linux land anymore. For a lot of people, that means that their favorite distro suddenly works in a different way.
This happens every time you significantly change something that people use and have existing workflows for, regardless of whether your change is beneficial on the whole.
I get no end of bemusement from open source advocates that think it makes any kind of rational sense to campaign against an open source project. THIS IS ALL OPEN SOURCE. Freedom and choice is the whole point, isn't it?
If you prefer an alternative or forebear to systemd, that is great. Use it. Advocate for the system you prefer. Convince people that the choice you have made is better.
Meanwhile the vast majority of distributions have voluntarily chosen systemd. Perhaps if its critics reflect on the reality of that shift, they could look at ways to improve the alternative to address its perceived deficiencies—just as GCC started doing now that LLVM has taken a bite out of their dominance.
Most arguments about systemd will devolve into a Motte and Bailey argument. The problems with systemd are all the stuff tacked on that are mandatory, but if you criticize them you'll get people switching to try to put words into your mouth about how the init replacement is good/bad.
The Motte is all the shovelware attached to systemd that is nearly impossible to detatch and the Bailey is the init replacement.
I have way too many cases of systemd startup items hanging with their timeout for no good reason.
Worse, my most complicated high-uptime machine usually does not shut down in a reasonable time. Systemd says "waiting for session user cracauer" (something like it) for whatever reason. It also hung on undoing swapspace, when that swapspace was a custom stack of block layers. I don't need swapspace to be "shut down". It went into 20 minutes something always stating another timeout when one expired. I mean, WTF?
The problem here is that I had to do an unclean shutdown on that machine (reset button) multiple times, and that I really can't have.
This also illustrates a point I have been making about Linux and the BSDs from day one: When the BSDs boot or shut down the keyboard is connected to the rc scripts. You can do Control-C for SIGINT and Control-\ for SIGQUIT, The latter makes everybody in the stack leave a coredump on disk.
Now, compare these two:
1)
in BSD when there is a startup or shutdown item taking too long or hanging I can abort that single item and I can later debug what was going on with the coredumps.
2)
on a Linux system with systemd I cannot "cut through" startup or shutdown items I don't want to wait for, and there is no way to debug any of that if the machine doesn't actually come up completely, or if thing happen at shutdown. The only interaction I can conduct is the reset button.
To add insult to injury, systemd also hides a lot of error messages that would traditionally be dumped on the console, and instead of giving me that error message systemd captures it and print on the screen instructions how to get that error message (which usually are longer than the error message was, WTF?). Instructions that I cannot follow because somebody detached my keyboard, and because I will never be in that machine in an up state while that context is available.
This also invalidates the point that systemd could be one platform that you learn once and then use on a wide basis. The debugging abilities are nowhere close to adequate, so you have to learn by try-n-error.
I've struggled with, and am still struggling with, units hanging on shutdown. It's my biggest complaint with systemD aside from journald eating its own logs.
I've been using magic SysRq to force hanging units to quit. SysRq + e sends SIGINT to all processes, and SysRq + i sends SIGKILL.
systemd errs on the safe side and thus it tries really hard to shut things down safely vs just yanking the plug. The timeouts are easily configurable if that's a problem for you, but I'd argue that if services hang too often for you, there's an underlying problem with your system somewhere, (i.e. your mounts or such, I'd consult journald for dependency cycles).
My experience with systemd has be extraordinarily positive. I like the unified syntax of unit files. I know that's like 50% of what systemd does, but it does it extraordinarily well.
Is systemd-nspawn secure enough now we can forget docker et all? I liked the idea of a "chroot" being supported by the service manager.
Notice that the text about slackware sounds a bit "pessimistic", as if it was a somewhat legacy distribution. Nothing further from the truth. We run a small farm of virtual machines with different up-to-date distributions, and slackware is typically the one that follows upstream packages more closely. For example it had gcc 9.1, bash 5, etc. a few days after they were released.
I don't like it when my process init and logging system also tries to manage my volume mounts. If I unmount a device, I don't want systemd going behind my back and remounting it for me.
It's non standard behavior changes like this that drive systemd hate.
Alpine is great. I have nothing against systemd but Alpine stands on it's own for containers and VMs. I haven't given it a try on baremetal but I imagine it does just as well there. Not really desktop focused but if you want to run it with a GUI on a laptop it's technically possible.
The biggest complaint I regularly see about systemd from those that don't like it is that it violates the UNIX philosophy by combining too many functionalities into one project.
Based upon this I found the following quote from the article in regards to Alpine Linux, a distribution based upon BusyBox which implements the functionality of over 100 usually separate executables into one, quite amusing.
> It is small and simple, realising the UNIX spirit to the core: doing one thing and doing it well.
The difference is that with busy box, everything is optional (just replace the symlink in /bin with another implementation), and designed as a drop-in replacement for standalone utilities (instead of redesigning them poorly from scratch).
The number of binaries is irrelevant. Systemd has a lot of binaries but is still called a monolith. Unlike systemd with journald, Busybox allows you to use Vim instead of Busybox vi without any trouble. Busybox might also emphasize the “small and simple” aspect much more than GNU tools, which have a reputation for being needlessly bloated (see all of the flags to cat, for example).
I have been running Void Linux since Debian switched to SystemD both at work and at home (including playing Skyrim SSE on Steam using Proton, or StarCraft 2 and Diablo 3 using Lutris) .
It is a very nice distro although I would not recommend it to beginners since it is a little rough around the edges if you want to do full disk encryption during installation.
Initially I switched to FreeBSD and then OpenBSD but I missed Linux conveniences like native cloud sync clients[1], Steam, Docker, support for the hardware I already had, etc.
I use void now on everything, work, home even my Raspberry PIs.
Can confirm that installation is a PITA. If you want something more fancy than the standard installation like an encrypted boot disk you won't get anything running without touching chroot a few times.
But once it runs it runs! The most "stable" rolling release distro I have tried so far. Something that can not be said about Gentoo.
The most recent reason I found to hate systemd was it replaced my system DNS resolver with its own (thus requiring me to modify /etc/systemd/resolved.conf, and doing the daemon-reload-service-restart-hokey-pokey, to get a host to function on a network+VPN like it did before). The only reason systemd has its own resolver is they wanted extra DNS functionality. Did I ask for these features? Did I want a new resolver? No. But that's the whole idea behind systemd. A few devs shoving complex features down everyone's throats, just because they felt like it. Operating system fascism.
But I don't think we should be angry at systemd developers; they can develop whatever they want. I'm mostly angry at the distributions who opted in to their crap. Systemd has not made my life easier, but it has often made it harder, and the only reason that happened was because a distro allowed it.
Debian shipping this despite the obvious backlash was the whole reason I jumped ship too, that and the frequent boot failures and looooong timeouts (which I'm sure someone will be happy to tell me are my own fault).
I've actually done sysvinit style setup before and had to migrate to systemd when it came out later. It's not that bad. It's just another way of running things. It's actually quite simple and consistent. It's a step forward.
Systemd is the worst init system except for all the others that have been developed from time to time.
Some of the trade-offs it makes, and its expansionist attitudes, are really grating. But it introduced a higher level of consistency in the Linux world for userland developers, which is almost invariably a good thing from a commercial perspective.
Nailed it. The hobbyists are revolting. Anyone interested in making their system do something odd and clever is having problems, and the people running linux systems 9-5 are busy calling us morons for trying or even caring...
[+] [-] AsyncAwait|6 years ago|reply
For example, people are complaining about logind being included, but forget that consolekit was unmaintained before that. Yes, there's parts to systemd that not everyone will use, like container support, but in that case you can pretty safely ignore that use case.
For me, systemd has provided a much more consistent way of managing services. There's a tightly defined service definition format that allows one to comfortably modify any 3rd party service as well, (unlike random, variable-quality shell scripts), relatively small amount of commands to learn that work consistently across services, mounts, timers etc. There's also much better handling of modern hardware, hotplugging & the like.
I can't say I miss sysvinit. Also, stuff like [1] from the anti-systemd camp doesn't inspire confidence.
1 - https://lwn.net/Articles/786593
[+] [-] markstos|6 years ago|reply
Based on my experience and all the anti-systemd posts online, I expected to dislike it.
But on it's merits I really like the consistency it brings to the "system layer" of the OS.
I find it's shame when developers skip over systemd for consideration, adding extra layers of complexity when systemd alone would have been sufficient: For example, using Docker when the basic isolation features of systemd would do, or using "forever.js" to manage Node.js processes, when systemd could could be saving 15% memory overhead per process, using software already installed in the base system.
On the other hand, I do support diversity of software and am glad to see some other options still being promoted and used. The dangers and weaknesses of monoculture in the physical world apply to software systems as well.
[+] [-] jimktrains2|6 years ago|reply
From my understanding, alternatives _could_ be written, but haven't yet and that means we currently having to ignore more battle-hardened software in favour of whatever is in systemd by default.
[+] [-] boramalper|6 years ago|reply
This is an interesting claim, mind throwing some pointers?
[+] [-] JohnFen|6 years ago|reply
Then you should not be wanting to see applications including a hard dependency to systemD.
[+] [-] fabiomaia|6 years ago|reply
[+] [-] sjwright|6 years ago|reply
https://www.youtube.com/watch?v=6AeWu1fZ7bY
BSDCan 2018—Benno Rice: The Tragedy of systemd
"systemd is, to put it mildly, controversial. Depending on who you ask it's either a complete violation of the UNIX philosophy, a bloated pile of bugs, a complete violation of the elegant simplicity it replaced or, it most cases, some or all of the above. So why have so many Linux distributions taken to it? Is it as bad as people say?
[+] [-] psadauskas|6 years ago|reply
He's from the BSD world, so his POV is as an (mostly) outsider.
[+] [-] blu3r4d0n|6 years ago|reply
[+] [-] JoshuaRLi|6 years ago|reply
[+] [-] sprash|6 years ago|reply
[+] [-] russellbeattie|6 years ago|reply
I'm not sure the presenter is condescending enough. Maybe he should have given an abbreviated history of Unix as well, oh wait, he did that.
[+] [-] microtonal|6 years ago|reply
https://www.gnu.org/software/shepherd/
That said, to me systemd has been a large improvement. Maybe it has its problems, but at least there is consistency in handling services and logs between Linux distributions, which is a big improvement over a bunch of homegrown sysvinit derivatives, Upstart, and homegrown non-sysvinit scripts.
[+] [-] telmich|6 years ago|reply
[+] [-] Mister_Snuggles|6 years ago|reply
The big thing, for me, that systemd brings to the table is consistency. Managing services on CentOS is the same as managing them on Debian which is the same as managing them on OpenSUSE. This makes it a lot easier to deal with the various different Linuxes.
Also, it seems to make writing a service a lot easier. Instead of the service needing to daemonize, write out a PID file, or whatever, it can just be a program that does its thing without forking, sends its output to stdout/stderr and systemd takes care of the details. I tried to go through this exercise on a FreeBSD system and ended up just installing 'pm2' to do it for me. I subsequently figured out what I did wrong, but pm2 is working and I see no need to change it.
Obviously systemd isn't suited for every use-case, but it doesn't seem nearly as bad as some people make it out to be.
[+] [-] nrclark|6 years ago|reply
What I _do not_ like are:
I'm very glad to see sysv-init on the way out, personally. I think systemd unit files are a huge improvement, and greatly improve standardization and init quality. But that doesn't intrinsically mean that the systemd project is doing the right thing.[+] [-] rzzzt|6 years ago|reply
[+] [-] beaconfield|6 years ago|reply
[+] [-] int_19h|6 years ago|reply
This happens every time you significantly change something that people use and have existing workflows for, regardless of whether your change is beneficial on the whole.
[+] [-] chapium|6 years ago|reply
[+] [-] sjwright|6 years ago|reply
If you prefer an alternative or forebear to systemd, that is great. Use it. Advocate for the system you prefer. Convince people that the choice you have made is better.
Meanwhile the vast majority of distributions have voluntarily chosen systemd. Perhaps if its critics reflect on the reality of that shift, they could look at ways to improve the alternative to address its perceived deficiencies—just as GCC started doing now that LLVM has taken a bite out of their dominance.
[+] [-] kevin_b_er|6 years ago|reply
The Motte is all the shovelware attached to systemd that is nearly impossible to detatch and the Bailey is the init replacement.
[+] [-] mjw1007|6 years ago|reply
[+] [-] mar77i|6 years ago|reply
Humans used to be able to disagree and still get along, but that was boring for drama-preventing reasons.
More on topic, though, I wonder: What exaclty is the relationship between Alpine Linux and ungleich.ch?
[+] [-] TazeTSchnitzel|6 years ago|reply
[+] [-] cracauer|6 years ago|reply
Worse, my most complicated high-uptime machine usually does not shut down in a reasonable time. Systemd says "waiting for session user cracauer" (something like it) for whatever reason. It also hung on undoing swapspace, when that swapspace was a custom stack of block layers. I don't need swapspace to be "shut down". It went into 20 minutes something always stating another timeout when one expired. I mean, WTF?
The problem here is that I had to do an unclean shutdown on that machine (reset button) multiple times, and that I really can't have.
This also illustrates a point I have been making about Linux and the BSDs from day one: When the BSDs boot or shut down the keyboard is connected to the rc scripts. You can do Control-C for SIGINT and Control-\ for SIGQUIT, The latter makes everybody in the stack leave a coredump on disk.
Now, compare these two:
1) in BSD when there is a startup or shutdown item taking too long or hanging I can abort that single item and I can later debug what was going on with the coredumps.
2) on a Linux system with systemd I cannot "cut through" startup or shutdown items I don't want to wait for, and there is no way to debug any of that if the machine doesn't actually come up completely, or if thing happen at shutdown. The only interaction I can conduct is the reset button.
To add insult to injury, systemd also hides a lot of error messages that would traditionally be dumped on the console, and instead of giving me that error message systemd captures it and print on the screen instructions how to get that error message (which usually are longer than the error message was, WTF?). Instructions that I cannot follow because somebody detached my keyboard, and because I will never be in that machine in an up state while that context is available.
This also invalidates the point that systemd could be one platform that you learn once and then use on a wide basis. The debugging abilities are nowhere close to adequate, so you have to learn by try-n-error.
[+] [-] webstrand|6 years ago|reply
I've been using magic SysRq to force hanging units to quit. SysRq + e sends SIGINT to all processes, and SysRq + i sends SIGKILL.
[+] [-] AsyncAwait|6 years ago|reply
[+] [-] Whatitat90|6 years ago|reply
All major distros adopted it and even some that are listed there as "no systemd" in reality just give you choice (e.g. Gentoo).
I'd gladly hear the opinion of distro maintainers why did they switch to SystemD if it's as bad as it looks like in people's perception.
[+] [-] exabrial|6 years ago|reply
Is systemd-nspawn secure enough now we can forget docker et all? I liked the idea of a "chroot" being supported by the service manager.
[+] [-] enriquto|6 years ago|reply
Notice that the text about slackware sounds a bit "pessimistic", as if it was a somewhat legacy distribution. Nothing further from the truth. We run a small farm of virtual machines with different up-to-date distributions, and slackware is typically the one that follows upstream packages more closely. For example it had gcc 9.1, bash 5, etc. a few days after they were released.
[+] [-] annadane|6 years ago|reply
[+] [-] telmich|6 years ago|reply
[+] [-] scurvy|6 years ago|reply
It's non standard behavior changes like this that drive systemd hate.
[+] [-] zamadatix|6 years ago|reply
[+] [-] telmich|6 years ago|reply
[+] [-] Cogitri|6 years ago|reply
[+] [-] eeZah7Ux|6 years ago|reply
https://threatpost.com/alpine-linux-docker-images-unlocked/1...
[+] [-] tssva|6 years ago|reply
Based upon this I found the following quote from the article in regards to Alpine Linux, a distribution based upon BusyBox which implements the functionality of over 100 usually separate executables into one, quite amusing.
> It is small and simple, realising the UNIX spirit to the core: doing one thing and doing it well.
[+] [-] hedora|6 years ago|reply
[+] [-] snazz|6 years ago|reply
[+] [-] mixmastamyk|6 years ago|reply
[+] [-] aerique|6 years ago|reply
It is a very nice distro although I would not recommend it to beginners since it is a little rough around the edges if you want to do full disk encryption during installation.
Initially I switched to FreeBSD and then OpenBSD but I missed Linux conveniences like native cloud sync clients[1], Steam, Docker, support for the hardware I already had, etc.
[1] this was before I discovered Rclone
[+] [-] sprash|6 years ago|reply
But once it runs it runs! The most "stable" rolling release distro I have tried so far. Something that can not be said about Gentoo.
[+] [-] peterwwillis|6 years ago|reply
But I don't think we should be angry at systemd developers; they can develop whatever they want. I'm mostly angry at the distributions who opted in to their crap. Systemd has not made my life easier, but it has often made it harder, and the only reason that happened was because a distro allowed it.
[+] [-] silversconfused|6 years ago|reply
[+] [-] telmich|6 years ago|reply
[+] [-] ww520|6 years ago|reply
[+] [-] toyg|6 years ago|reply
Some of the trade-offs it makes, and its expansionist attitudes, are really grating. But it introduced a higher level of consistency in the Linux world for userland developers, which is almost invariably a good thing from a commercial perspective.
[+] [-] silversconfused|6 years ago|reply
Nailed it. The hobbyists are revolting. Anyone interested in making their system do something odd and clever is having problems, and the people running linux systems 9-5 are busy calling us morons for trying or even caring...