Voice of the Masses: Have you changed your mind about Systemd?
Systemd, the “bag of bits” that originally started as an init system but has since taken over a lot of the lower-level plumbing of GNU/Linux, has a controversial history. Some distributions were quick to take it up, whereas others were more hesitant, arguing that it was subject to feature-creep and violated some long-standing Unix principles.
Today, almost every major Linux distro has adopted Systemd, and most of the old flamewars have burnt out. So let’s start a new one! Only kidding, but we’d like to hear from our readers and podcast listeners: have you changed your mind about Systemd? Were you once fiercely against it, but have come to appreciate it now? Or conversely: were you an early adopter who liked its technology, but in the meantime prefer the old Sysvinit approach?
Let us know in the comments below and we’ll read out the best in our next podcast! (It’s been a while since the last one due to deadlines and travel, but we’ll be back and bursting with awesomeness next week.)
Related Posts
About The Author
Mike Saunders
Mike stores his data by printing out hex dumps and laminating the sheets. He's the author of The Haynes Linux Manual and the creator of MikeOS, an operating system hand-built from assembly language.
It is pretty much a non-event. The collapse of civilization, end of the world, famine and pestilence don’t seem to have happened.
Oh – and who exactly claimed that famine will happen? Please cite links.
This is the typical level of “quality” that you can read from pro-systemd proponents.
Straw man build-up like Stuart did there.
At risk of sounding incredibly pedantic, it’s systemd rather than Systemd.
Yes, that was their choice. As journalists we believe proper nouns should have capital letters at the start 🙂
I liked systemd since I first tried it. Never changed my mind.
Pretty much systemd works and tidies up a lot of loose and disparate ends.
My only beef with it is the logging. I preferred the way that syslog/rsyslog worked. My logging analysers don’t seem to have caught up with systemd logging yet. As a result I have had to do extra work to cope with my remote logging sources and Glogg analyser configuration.
To be honest, I haven’t noticed it.
Same here.
I haven’t noticed a difference at all, with anything, as I use Slackware! (For obvious reasons!)
Arguments all seem to have revolved around Sysvinit vs Systemd however Slackware’s init system uses the BSD style (notwithstanding the compatibility bits and pieces of course) which seems to be a lot simpler than Sysv anyway. My (admittedly selfish) question to the more enlightened and knowledgeable souls out there would be along the lines of ‘are there any advantages to using Systemd over the simpler (than Sysv) BSD init system?’ (Apologies for going off-topic… )
Would anyone prefer the BSD init system as a 3rd option over sysV or sysd?
Yeah, slackware stays true to the oldschool cause.
If you boot often, as you do on a laptop, then the huge decrease in boot time that systemd gives is very noticeable and very welcome.
Combine systemd with an SSD and the BIOS screen becomes the longest part of the boot process.
Hmmm… I don’t really notice any difference in boot times. Systemd or not systemd doesn’t seem to make much difference to me.
Probably SSD disks with extremery fast seek times get the most benefit when the machine is booted by Systemd. Many services are started simultaneously and disk must seek data everywhere but it doesn’t matter with SSD’s.
LoL On the very same Debian 8, systemd actually consistently took several seconds longer to boot than sysVinit. Sometimes it would even wait several seconds just for some one job. (But that must have been because of me being full with hate and me not wanting to change etc. =P)
Is systemd faster than upstart?
you want fast boot times
build a custom kernel with all the modules for your laptop hard ware built in to the kernel
this cut my boot tome in half
For reference: systemd-219-27.fc22.x86_64
Just last week, init/systemd crashed. Not sure what happened but init was not running. The system stayed up surprisingly, but trying to log in was painful. Had to do a force reboot.
Generally, systemd is “ok” to me, but I’m not happy with binary logs and there’s little issues that crop up from time to time. annoying, but liveable I guess.
primum non nocere. First do no harm. I didn’t like the idea that too many things have to change to accommodate a new system. I still don’t. systemd developers (maybe necessarily) appear to have little regard for existing applications and utilities, and if they break, it becomes up to their developers to fit in or get lost. tmux is a case in point. I don’t believe it was necessary to work this way…after all upstart managed it quite well. In the end the common /(wo)?man|sense/ is not important. Most defintely systemd is not a victimless crime.
Fragmentation = diversity. But fragmentation = bad and diversity = good. There breaks Euclids first Law. For me, and I guess for the majority of non-sysadmins/non-developer/non-hacker community it has not made a noticeable difference. Is the boot up quicker? hardly…I have an SSD and the BIOS has always taken much longer to load than my OS. Do I feel more secure? nope…just as secure as before. Do I feel great at being able to have super-fine grained control of the systems daemons and boot processes or whatever systemd/initd does? can’t say i have ever thought of it. In a way this is a testament in favour of systemd in abstracting out its operations invisibly. Ideologically, while I oppose fragmentation, I am glad Devuan exists, and hope developers don’t turn init into a monoculture.
As an average desktop user who does nothing exotic with his PC, the price of cheese on Venus has more bearing on my life than the init system my PC uses.
Until differences in vulnerabilities are exploited.
I have not changed my mind. Sometimes you need a asteroid strike to wipe out the dinosaurs, so that a more adaptable species can take control. Dinosaurs make for cool stories, but are not great company. And what was with those piddly arms any way?
and sometimes the dinosaurs evolve into top tier predators like eagles, sharks, aligators. which is to say, they were better adapted.
Yeah, whether you’re a darwinist.
I wouldn’t call it a change exactly: I didn’t think it was such a big deal then, and I still don’t. Some people just go looking for a reason to put their panties in a twist, and for a while this was one. A tale told by an idiot, full of sound and fury, signifying nothing.
I get the impression there would have been less controversy if it had been gradually introduced over a number of years & expanded by a wider group of contributors. This would have ensured buy-in from the open source community and maybe fixed some of their zanier decisions.
A fast-growing leviathan built by a small group that looks like it’s going to take over everyone’s system and eat up core components that definitely work is a scary thing, and fear provokes hostility!
All the Linux distros I’ve tried in recent years have worked so well OOTB that I’ve not needed to fiddle with anything in the startup scripts. So I’ve really not noticed any change.
It does worry me slightly that one day I might need to change something and then I’ll feel lost.
Nope, I still like it and the more I learn the more I like it. For example a couple of months ago I migrated my cronjobs to systemd-timers – and it is sooo much better.
Positive: Much quicker restart on my laptop from standby. Also like the journaling and standardized format for error messages (although they still don’t offer the clarity of OpenVMS messages).
Negative: The main application I’m responsible for at work is not yet systemd compliant, i.e., the vendor still uses the old init scripts for startup. I have to write a systemd unit file, but just haven’t had the time yet. That means I’m not able to run the latest version of the enterprise Linux distribution. Luckily I still have some years of vendor support left on the Linux version I’m having to run, so I’m still receiving patches/updates thankfully.
I have written a few systemd unit files and they seem to be quite simple to get up and running with.
As an occasional sysadmin I find the output of “service foo status” quite handy as it shows you a chunk of the logs etc.
So, yes, my mind has changed but only from “this is something I don’t care about” to “this is pretty cool”.
It depends on if you’re a Linux end user or a system administrator. I’ve been a professional sysadmin for 16 years now. I can’t remember the last time I booted into a graphical environment on Linux (except at install-time). I don’t run Linux on my laptop (it’s a Mac, life’s too short) or desktop (Windows, ditto) PC, and simply log into a local VM when I need to do work offline.
If you’re a local Linux desktop user, you probably didn’t notice the transition unless you were hit by any of the weird, hard-to-diagnose bugs. For everyone *else*, it’s been one cluster F after another for very, very little gain that wasn’t already easily achievable through existing means (tcpserver, daemontools, xinetd, cgroups managers, bash -> dash, syslog, etc) and takes well-known, small components and hides them under an opaque binary blob that you have to trust to do the right thing.
Over the last six years, my stance hasn’t changed on the project, but I’ve come to more and more of the conclusion that server and desktop distros need to separate out. And heterogeneous diversity at all levels of the ecosystem is healthy, and a good thing.
You sound a lot like on of those admins that got hit hard by systemd, mostly because they went in unprepared, assuming that with 16 years of adjoining under their belt they will be able to figure stuff out on the go. That does not work out: systemd is significantly different from the old ways, you need to do a bit of reading or you will have one cluster fuck after the next.
Yes, systemd did not bring any new functionality that was not available before. Yes, it has its quirks, lots of them. But it does finally provide a consistency to the base layer. And it does improve on the status quo in lots of small ways. It makes things more reliable, if you do not mess up the configuration (a good admin can break any system). It is the first init system that actually provides services that developers find valuable enough to have their software depend on it. And finally it makes things so much easier to debug with proper loving of everything everywhere and clear warnings when logs become “strange”. They did that before too, there was just no way you could tell).
Don’t shoot the messenger, shout the idiotic system that kept the issues hidden from you for all these years. Then fix the bugs your system ignored for years, and then you can lean back and enjoy the consistent and powerful base layer that Linux has been missing for decades.
I was probably more prepared than most, as I followed the Fedora devel list heavily (and still do) since I have RPMs for software I work on that need to stay up-to-date. Many, many other admins only paid tangental attention to it because they were too busy with their day jobs. (No one runs Fedora directly as a server, they run RHEL or CentOS (or another rebuild).) The previous transition from original SysV to upstart had been pretty transparent because it didn’t fundamentally alter how the startup process proceeded. Sure, there were a few tweaks in how getty was handled, but that’s about it if you didn’t try to use any advanced features. It was assumed that the impact of moving to systemd would be low because it was assumed that the pro’s at RH understood reliability engineering.
Of course, that’s just how it was *sold*. If the monstrosity it is now had been publicly proposed then it would have been tossed out. Why? Because no one in the server space *wanted* a unified base layer making decisions for all distros. It’s the same debate we’re about to have with Canonical snaps, only this time people are fully aware of the perils of this type of action.
systemd has neat features, but at high cost.
Consistency? In RH world, we already had that. Debian and Ubuntu init scripts sucked, but RH ones were simple and standardized. When you crossed distros, you knew you were going into a different environment. ISV’s might have cared (had they not tossed out LSB), but not Linux admins. And many of us are also dealing with non-Linux Unices, which systemd doesn’t give a crap about.
Reliability? Hell no. Reliable systems are deterministic, with dynamic bits bolted on. Someone’s laptop might need a more dynamic design, but that makes things inherently *harder* to debug, not easier. Especially at 3am on a crisis bridge. There’s a reason system startup and service management had been broken out into to two separate things, they’re two separate activities.
Logging? If you needed systemd to do logging correctly, then you weren’t doing logging correctly.
“It is the first init system that actually provides services that developers find valuable enough to have their software depend on it.”
That’s a bug, not a feature. No software not involved in system initialization should have to depend on a specific init system.
> Because no one in the server space *wanted* a unified base layer making decisions for all distros.
Apparently the *distributions* wanted that. If they did not, then they would not flock to systemd.
> Consistency? In RH world, we already had that. Debian and Ubuntu init scripts sucked, but RH ones were simple and standardized.
All init scripts suck, but I admit that some suck less than others.
> Reliability? Hell no. Reliable systems are deterministic, with dynamic bits bolted on.
I can define pretty well when things will happen in systemd, based on all kinds of triggers. Those triggers are not fully deterministic in any resonably modern system!
Systemd only provides the tools necessary to handle that.
> There’s a reason system startup and service management had been broken out into to two separate things, they’re two separate activities.
You could move the service management into separate processes. But who watches the watchmen then? What happens when your service managers locks up?
You need monitoring code in init to detect that (there is that even in sysv-init to restart gettys). So now you have two sets of monitoring code in your critical path: One set in init, the other in the service management processes. Twice the potential for bugs:-)
I think integrating service management into PID1 makes a lot of sense to avoid this duplication of functionality. The hardware will monitor PID1 via the watchdog timers, PID1 will monitor the services and you have everything on the system covered.
> Logging? If you needed systemd to do logging correctly, then you weren’t doing logging correctly.
I need systemd to push a lot more data into the logs than ever before. I need systemd to be sure I can trust some of the data in the logs (e.g. the process id), something that was easy to fake before.
> No software not involved in system initialization should have to depend on a specific init system.
Systemd-the-init-system provides three basic services: logging, communication and cgroup management. I think having these services at the heart of a modern Linux system makes a lot of sense. Other software making use of these services (via other services layered on top of these core three) also makes a lot of sense to me.
What does it matter what users think?
Developers write the software, distributors package it, users and admins have to take that or leave it.
So without developer buy-in there just is nothing to administer or use.
There are no developers outside the systemd universe. Go check out devuan: it is basically a society for the preservation of old software with old bugs and problems. That is totally boring for devs that crave to add new bugs and new problems:-) There is no serious attempt at solving any problem or to improve anything there (save for some homework-grade attempts to program riddled with compiler warnings).
Whether or not you like systemd does not matter. Without alternatives it is want is going to stay for the next years.
“Without alternatives it is want is going to stay for the next years.”
Are you saying there are no alternatives to systemd? Excuse me, but you must be painfully ignorant.
There are lots of alternatives to the sysv init/rc. There is no alternative to systemd init that can manage cgroups as conveniently and consistently. Making those convenient is a game changer!
There are even less alternatives to any of the plumbing projects that are in the systemd repository. You want dynamic device management? You need udev — at least there are a couple of forks of that code. You want to run your UI in a secure way? You need logind (not even a usable forks for this). Consistent logging of everything? No alternative to journald. You can install other logging services, but none gets you logs as complete as journals, as that changes how logs are collected and not only how they are stored.
My point is that systemd solves problems developers face that no other Linux project addresses. Nobody attempts to do that, so we are stuck with systemd. Things like Wayland needs to depend on systemd APIs (not just for init, but for a wide range of things!), simply because there is no other safe way to grant a user access to the device node Wayland needs to access and to *withdraw* that access again when something else should take control of those device nodes.
Sorry, to break it to you: We are stuck with systemd for the time being.
Nope, my opinion hasn’t changed. I still avoid it by using distros like Void, antiX, and the BSDs.
Still living happily without it
No. I liked it from the moment I understood what it is and how it works. And the more I understand it the more I appreciate it. It’s well designed.
It works. The primary objections to it seem more philosophical than practical. That’s not the say that I necessarily disagree with them, but the darn thing does seem, most annoyingly, to work.
Sorry I (will) miss the ultimate flexibility of init scripts. systemd is just another layer of learning, sure I will get to grips with it over time but why? It sounds like all the pain of having to tooth extacted only to be told well you didn’t really need to have it taken out. Of course for those that are in ignorant bliss using systemd (yes including me on my home desktop) will not be an issue (until something goes wrong), and you could probably say the same about ye olde init script … but scripts I can handle … systemd well I guess I will find out when all those Red Hat boxes get upgraded from 5 to 7 … and I have to somehow shoehorn some custom init scripts into systemd ouch !
I didn’t have strong feelings about systemd, but I still feel sorry for the upstart team.
You don’t have to, since there was no team left at the time Ubuntu switched.
systemd wtf I have never noticed it 😉
http://m.mlb.com/news/article/184690478/michael-saunders-hits-3-home-runs-vs-orioles
Yes, I’m very busy thesedays 🙂
In the end it still has the same fundamental issues, but the more worrisome part is how quickly it was rolled out throughout a wide spectrum of distributions given the vocal arguments surrounding it. It really give you pause about the influence of large business sponsors, who would rather take an easy route than one more in line with the fine grained competitive nature of the open source world, overruling certain sections of the regular user base. I hope this is not a trend where the push for widespread Linux commercialization increasingly detracts from the users’ influence and experience, as we’ve seen with Canonical’s as well as Google’s ventures.
So the sysadmin guy who says there should be more of a difference between desktop Linux and server Linux… also thinks that you could do everything with SysVinit and a dozen other tools that you can do with systemd. Close but not really… as some of those tools were really hard to use… so most folks didn’t use them. Anyway, now you can do all of that stuff but with systemd related commands… and no, it isn’t a single binary blob.
I actually quite like SystemD, the dependency stuff is pretty neatly done.
What I really don’t like though is the documentation. I’ll argue ’til I’m puce that it’s dire. So next time Lennart is reachable, please, please, please could you ask him to do a “SystemD for dummies” – we aren’t all in the Code Valhalla that he lives in. Manual pages are great for reference, but make a poor tutorial
Systemd is still what it was initially, only now even more so: An abomination. The reason why some in the systemd propaganda-camp are claiming that systemd “has won” is simply that most competent administrators have found a way to avoid it. For example, while not the default anymore, it is pretty easy to use the classical, reliable sysIV init on Debian, and only have minimal inert systemd cruft lying around.
That is also likely the reason why Devuan is not very active. I predict that if that possibility vanishes or using sysIV init gets very hard, we will see a real war. For example, my employer will move away from Linux if necessary. There is no way systemd will ever make it onto our servers. We need reliability and security, convenience is a distant third and systemd does nothing good for all of these when you are administrating servers.
Still avoiding it. After being an enthusiast for some years, having bought on the standardization, on the modularity lies, and on the dependency based boot, I abandoned systemd after getting fed up not only with the developers attitude (we’ll break up everything we don’t understand – see NOHUP – and we’ll keep ignoring standards because it might be fun), but also with the brittleness of the boot process (failing to boot because of a missing, non-essential filesystem or module that failed to load???), and the growing replacement of existing tools with half-finished ones (like resolved for instance, or the ntp replacement). When I had a laptop failing to boot after failing to shutdown (and finding out that systemd had disabled sysreq), I gave up on it and thanking the gods for separate /home partitions, formatted the / and installed a systemd free distribution.
If you are a desktop user and never use a NFS share, or do anything else not understood by systemd, you probably haven’t noticed it. If you are a power user or sysadmin, you probably have switched/are switching to *BSD, or at least to a sane linux distro, like MX, Devuan, Slackware, PCLinuxOS, Gentoo, etc.
And if you are a fanboi, you’ll probably be preparing by now some denial message, citing the fallacies of the “biggest myths” propaganda page, and claiming either that Devuan guys are doing nothing, or are doing too much (like removing libsystemd), and that systemd destiny is to rule all linux world.
As for the systemd-free distros, it’s kinda surprising how often we forget an otherwise easily available and even good-looking one: Linux Mint Debian Edition. It’s virtually Debian 8, looks good, and last time I checked, it still used SysV init.
Multibooting Mint, Ubuntu, Win10, WinXP, and PCLinuxOS in different flavors. My favorites still PCLinuxOS KDE and MATE without systemd.
Are you people kidding? I HATE systemd, it’s garbage. I am a system administrator, I work on linux all day every day. systemd did nothing I can see that’s helpful and a lot of stuff that sucks. What’s just as bad, you have to really not be paying attention to see that Lennart Poettering is taking a dump on the philosophy that has gotten linux this far. I can read shell code, I could figure out what was going on. Now it’s hidden in crap binaries and no one knows how things work. It may be fine or even good for desktops. Who is using linux for their desktop and why? Linux is running the servers that make up the infrastructure of the net. Why would you screw up the Important server distributions just to try and improve things for the desktop. if you’re using linux for the desktop you are some kind of fan hobbyist and you should deal with it. Use a mac or windows, they are bettet. But for a server, linux was the best…now it’s crap. Not exaggerating. I won’t run systemd on my servers if I can avoid it. I’ve ditched linux for freebsd. It really sucks to see something you loved turned into crap and a bunch of dinwits sitting around saying…yeah it seems better for playing music on my laptop. It’s the worst thing to happen to open source since it began. I hope enough devs cone to their senses to put together a real alternative distro since debian sold out and in turn made their distro a useless copy of redhat as well.
It was a bad idea back then, it is still a bad idea now.
On my machines, I use my own simple init written in ruby, and two dead simple BSD-style rc scripts in bash to bring the system up or down. Plus a handful of simple init scripts for services, network, eudev, crond, syslog, sshd. And it still boots faster than systemd, despite using plain old bash scripts and “wasting” quite a few PIDs on the way.
Init spawns and respawns gettys, reaps children, traps HUP, USR1 for shutdown and reboot and implements killall5 needed from rc.shutdown. So it integrates the old sysv-suite in one simple script, while even taking away features I never used. Rock solid, deterministic, simple, compatible with more sophisticated service management tools, should the need ever arise.
The whole system can be read and completely understood in in a few minutes.
Sounds great! Are your bash and ruby scripts open for viewing? (GitLab or the like?)
Do you really want to see the piece of crap systemd is, read the code, see the visible and obvious bugs.
And that one up there saying systemd is here because it makes life easier and fun for developers, I tell you, those you are referring too are obviously nothing more than ex MS visual programmers, not real devs and they should just go back to their beloved Windows… and look Win10 crap is there for them to play with, they don’t need to fondle and break what they do not understand.
Don’t belive me? … check:
https://www.theregister.co.uk/2017/01/24/systemd_flaw/
And you don’t want to start with the code, than please don’t stop there at the simple article, but start digging from there down.
https://mobile.twitter.com/AlecMuffett/status/779941674671898624
And deeper…
I’d go into the tech details but the a-holes that think systemd is great because ‘my system boots’ fast’ don’t have a clue. Those types of a-holes wouldn’t bother to read why systemd sucks anyhow.
My systems stay up for months at a time. Only reboot on kernel upgrades. I could give a rats ass about boot times which are quick without systemd.
In a nutshell – systemd sucks. If you don’t know why – you don’t have a clue.
It is not that systemd is a crap idea, or that it doesn’t work. That should not be the issue.
The problem with systemd is that RedHat push their own software onto the rest of the world.
They have done the same with xfs in RHEL7, which anyone over 30 will tell you is inferior to ext3 or ext4. Just google it.
But the thing that gets me is RedHat now have a virtual monopoly on the server market with rhel. Far more than Sun or IBM ever did with their real Unix’s.
The sad thing is the way people think it’s opensource, when they don’t really understand what the term means.
RHEL is only one very average distro that has had fantastic marketing and now has a multi billion dollar company behind it.
It’s just all wrong. They are changing Linux into a proprietary OS, but unlike Solaris or AIX it is just a jumble of thousands of bit of free sw that that have successfully packaged and added to to make it incompatible with anything else.
RH are huge and they make billions from their licensing.
To make matters worse they cancelled RHCE for ver6 so we all have to recertify on a new OS ver7 that many big companies are too scared NOT to use.
I hate them I just freaking hate them. arghhhhhhh!
FTR, I started on linux with Yggdrasil and slackware while Redhat linux was about ver 2.0 so I’ve seen the whole UNIX world change over the past 20 years.
Personally I know that Solaris is the BEST UNIX OS ever created. Oracle took it and have buggered it up, but it is still 1000% better than RHEL will ever be.
BUT oh no, it’s not opensource. WHO cares?
How many people look at the source code?
RedHat’s licensing is about 50% more expensive per core or per thread than Oracles. Solaris 11 x64 is years ahead of Redhat.
Sun invented zfs, zones, containers etc. RH just copied the ideas.
zfs is so much more advanced than xfs that it is almost funny that companies think they are being clever using rhel.
But the world has changed and no longer is the best operating system the one of choice. It is now the best marketed one, and than unfortunately is redhats bloated offering.