The D in SystemD stands for Dammmit... Security holes found in much-adored Linux toolkit Security biz Qualys has revealed three vulnerabilities in a component of systemd, a system and service manager used in most major Linux distributions. Patches for the three flaws – CVE-2018-16864, CVE-2018-16865, and CVE-2018-16866 – should appear in distro repos soon as a result of coordinated disclosure. However, Linux …
Gentoo & OpenRC user, here. Smug mode has been on for years -- ever since that bit in the handbook where one runs `make menuconfig` for the first time. (Hint: CONFIG_SMUG_MODE. Don't compile as a module unless you want to faff about in `/etc/modprobe.d/` for longer than is general considered "fun".)
This post has been deleted by its author
Void wasn't always so pure and untainted... in fact I hadn't realised until a month or two back that they'd abandoned systemd ages ago and so had ignored it up until then.
Which is a shame, as it turns out to be a great distro, a huge breath of fresh air in terms of lack of bloat. I'll stick with Gentoo for my desktop, but for lower-powered machines or those random laptops lying around Void is my default choice now.
heh, no 'joke alert' here, and I'm laughing and pointing a big fat finger [guess which one] at systemd!!!
[and here I was, a good part of the last couple of days, setting up a Devuan VM for 'droid development - all of those downloads, my old 'droid dev setup in Mint wouldn't upgrade settings without crashing, might as well move it to Devuan , install clean, and go forward]
from article title: "Security holes found in much-adored Linux toolkit"
'much-adored - yeah I saw your tongue firmly ensconced in your cheek!
PulseAudio got a bad reputation with me because despite claiming to do things I wanted it completely failed to deliver; not helped by the fact that the minuscule amount of "documentation" available was either wrong or useless. Jack works pretty well on the rare occasions I need that kind of really careful attention to audio paths and ALSA / dmix works perfectly well everywhere else.
ACK on 'Jack', if you need some universal 'layer' that has some additional [and somewhat interesting] features, Jack seems to do the job. On my FreeBSD boxen, both Pulse and Jack are installed, because ports/packages seem to want them. No problems noted, though. And no Alsa (since FBSD is OSS).
Other "antiquated Unix philosophy" they didn't follow:
(1) small tools, each of which does one job well
(2) run daemons with minimum privilege
(3) reject unparseable configuration options, don't silently ignore them
Illuminating search: https://www.startpage.com/do/search?q=site%3Atheregister.co.uk+systemd
I had forgotten that systemd had won lamest vendor Pwnie award.
^ Dear $deity this! That's probably my biggest complaint about systemd. So when I change the config of something then start the service if if bombs out just show me the bloody error message!
But no, we have to use another util which mostly tells you sod all about what really went wrong and you have to hunt around for the original command, then run that yourself just to see the actual error message.
Or use an OS that lets you preallocate any ports to specific users...
mac_portacl: https://www.freebsd.org/doc/handbook/mac-policies.html#15.5.4
It wasn't as friendly as SystemV or even the BSD initscript systems. All the scripts are stored deep within several nontrivial directories, and enabling and disabling items wasn't as simple as using the chmod command in /etc/rc.d. Setting run levels were also nontrivial, I found it hard to switch to a CLI run level if anything (say, an installation of the amdgpu drivers gone pear-shaped) should prevent the initial XOrg server with the display manager from starting.
Systemd started as a noble project to revise what is, I'm afraid, the utter shambles that is Linux system startup. And for that, it should be praised.
The fact that along the way it's suffered one of the worse cases of mission creep ever recorded in the annals of history shouldn't take that away from it. But yes, now that it's pretty much its own OS these sorts of things were bound to happen.
Someone else here still reads Warstall I see
The politician's syllogism pre-dates Tim Worstall's columns for El Reg.
"ystemd started as a noble project to revise what is, I'm afraid, the utter shambles that is Linux system startup"
I agree that System V startup is a complete mess, but I don't understand why Linux doesn't use BSD's startup system? Its extremely simple and very easy to navigate. The average /etc contents of a BSD system is 10% the size of Linux. And it does the same job - ie - it starts stuff!
"The fact that along the way it's suffered one of the worse cases of mission creep ever recorded in the annals of history shouldn't take that away from it. "
If by "that" you mean that it had a "noble goal", I don't disagree. But the all-encompassing nature of systemD makes it not fit for purpose, and for that, I condemn it wholeheartedly.
"Systemd started as a noble project to revise what is, I'm afraid, the utter shambles that is Linux system startup. And for that, it should be praised."
There was _ABSOLUTELY_ _NOTHING_ _WRONG_ with the System V startup method as implemented by the Debian-based systems... well maybe ubu did something bad, but that was THEM, not System V
/etc/init.d/rc* - easy to use. easy to 'grep' for things. "how do I XX with YY" - find /etc/init.d | grep "YY"
I could make comments about millenials (and those few oldsters that 'enable' them) "feeling" that old ways+things are always BAD, and _INSISTING_ things be done *THEIR* (new, shiny) way, and arrogantly FORCING THE WORLD into "that" "solution", but I digress...
Actually Sys V was slow and didn't handle parallelism or dependencies gracefully.
Systemd is not a good solution to those problems, but there were problems berfore it. Certainly not problems that necessitated zerging the logging system or config files. The good news is that that putz (poetts) and his flying monkeys have totally learned their lesson. Oh wait, no they haven't, in a speech to the NY Linux User Group, he has stated they are implementing IPtables in SystemD, complete with a whole new syntax that is different than than the native system. But since that means the existing code won't have visibility of is SystemD packet mangling monkey magic, you won't be able to see why someting is/isn't being blocked until the routing core is re-written, or replaced with something in a totally different location, with different syntax, and incompatible with all code not specifically written for it. (Link for the masochistic, https://www.youtube.com/watch?v=_obJr3a_2G8)
SystemD!
To improve things, things must change
We are changing things
Therefore, we are improving things.
But hey, BSD right? great packet filtering and firewall code to. Great stuff. Still cant use it at work cause the bosses barely tolerate Linux and fear anything w/o a GUI.
I'd try to offer some code commits to those fighting the good fight, but FF 64 borked a decade of curated links in my bookmarks, so apparently I have to wright a replacement. Woo Hoo.
Also, shitty error handling.
One of my boxes wouldn't start the desktop and the error message was:
systemd systemd-logind.service failed
along with a message saying to use "journalctl" for more info. When I ran that command, I got:
systemd systemd-logind.service failed
If I wanted error messages like that, I would run Windows.
In the end, I spent many hours Googling it and never got anywhere. In the end I went to http://without-systemd.org/wiki/index.php/Alternatives_to_systemd and blew systemd and the desktop away and installed SysV/xfce. At least I can use my box now.
This post has been deleted by its author
SystemD is a total piece of shit. In fact, Linus was so fed up with the antics of one of the developers that he banned the guy from contributing to the Linux Kernel. This is why I use FreeBSD for my servers. Fast, reliable, and shit free.
SystemD violates the Unix way of doing things: Have one tool to do one thing and do it well.
This is why we have tools like chmod, chown, chgrp, ls, mv, cp, rm, mkdir, rmdir, cd, etc... All those tools do primarily ONE thing, and they do it well. The login tool handles user logins. Cron handles timed start of tasks (think Task Manager in Windows). SystemD just gobbles up all the startup tools for the sake of a faster, parallel boot strategy. Unix systems do not restart every 5 minutes, so it's a useless endeavor for a non-problem...aka a waste of time.
This is not really the problem with systemd actually that part (units and dependencies) is quite useful. Early on they highlighted the possibility of a faster boot as a "cool thing" it could do (and on desktop linux that's fairly useful), but it was really meant to be about standardising startup scripts to make them easier to manage. Sadly, whenever they got to a tricky bit the response so far has always been "it'll just be easier if we reimplement it ourselves".
"standardising startup scripts to make them easier to manage"
Easier to manage by whom? WIndows admins? SysV scripts are shell scripts. Anyone setting up a startup script on a Unix box will be familiar with the shell. Anyone who wants to treat it as if it was another OS really shouldn't be doing that.
You mean SHOULD. Otherwise, you're discriminating against newcomers who nonetheless need to be able to Do Stuff.
Unless you're willing to just tell them, "This Is Not For You." AND tell them where to go (without shooting yourselves in the foot as they make a mess that affects YOU, too), it's your mess. CLEAN IT UP.
I don't by the 'newcomers' arguments. I was a 'newcomer' once. I spent a bit of time learning to use the tools like 'grep' and 'man' and soon became very good at doing things.
I expect that others are more LIKE *ME* than are like 'st00pid windoze 1uzer$"
Also, there were tons of great HOWTOs and tutorials to get people past the basics. The Systemd people couldn't even be bothered to complete the internal documentation, let alone work with the community to prep the documentation BEFORE they released it.
The stuff they cam up with wasn't really EASIER, just different and INCOMPATIBLE.
WTF does that have to do babykitsystemd, Chuck? Those people not only don't care which init their system uses, they don't even know an init exists at all. This isn't a problem for them, because somebody else takes care of their system. As long as they have a network connection, a browser and an office suite (and whatever other "productivity" software they (think they) need), all easily clickable from their desktop, they'll happily point & drool. These people can use BSD, OS/2, Plan 9, Linux, OSX or whatever Redmond is pushing these days. It simply doesn't matter to them ... IF their system is setup by a competent tech. This is probably over 98% of the userbase.
The whole babykitsystemd argument is between mostly clueless fanbois and actual techies, with the fanbois mindlessly agreeing with the decision of their distro of choice, and the techies saying "Now hang on a sec, what exactly does this give me that I don't already have ... and what is it going to cost me in the long run if I switch?" ... From what I've seen, after giving it due thought almost all of the techies want nothing to do with babykitsystemd. The fanbois don't think, their thinking is done for them by their distro maintainer. For small values of "thinking"; I suspect most down-stream distros are simply following the path of least resistance.
By manage I didn't mean write, I meant take care of their interactions and dependencies, make things a bit more systematic and predictable.
Even in that it's arguably gone to far, a little while ago we had a NFS server that stopped serving NFS on startup. Fine, log in, start the service, wont start... why? It turns out that systemd automatically generates dependency modules for things that aren't really its business, in this case fstab mounts, and then decides these are dependencies for the nfs service if they happen to be exports. An exported filesystem fails to mount? Then no NFS for you my friend. Okay, let's remove the affected filesystems from the fstab. Still no. It turns out that these automatic modules are created at boot, but not rechecked, there's a command to force a reload, but the whole situation is an unnecessary one created by trying to be too clever. The systemd eventual solution will probably be to incorporate nfs and the linux filesystem modules into systemd...
On servers, FreeBSD is fine. On desktops it's the most Linux like of the BSDs, and not entirely in a good way.
I've had a fair bit of wrangling trying to get it to work on a Thinkpad X240 (it has issues with EFI, and USB3), and once its on wireless doesn't work. This is after discovering that you have to create the wireless interface - it doesn't just pop into existence like the other BSDs. Then once created the wireless doesn't work anyway, this is probably because the firmware for the Intel 7260 is non free, but this isn't documented in the FreeBSD docs and I haven't bothered to run an install when connected to a LAN yet.
It *is* documented in the OpenBSD manual pages, which tell you a post boot automatic fw_update is necessary to get it to work.
However, whilst I'm a huge fan of OpenBSD, I'd also like to occasionally run things such as Wine, some Linux apps, and use an NVidia card. All those things won't happen any time soon on OpenBSD (although you can get them to work on NetBSD, as long as the Nouveau driver is used)
As recommended above, Void is quite BSD-like in many ways (including a ports-like packaging system.) It won't hold your hand in any way though, so maybe isn't the easiest way in to Linux; the documentation is fairly minimal but other than the init system and package management there's really nothing void-specific so there's tons of useful info online. (The Arch wiki is very good for example, though I don't personally like the distro.)
I'd probably suggest Devuan, although I use Salix. I generally use Linux just as a Xen dom0 rather than a day to day OS.
I personally use Salix, because I like a fairly minimal Linux. Other people have mentioned Void which sounds interesting but I haven't tried. I haven't tried Devuan, but I have used Debian pre systemd and it's not bad.
Slackware (without additional software) doesn't include dependency tracking when installing software, which is a right pain. It doesn't include Network Manager, which personally I think is a huge bonus.
Salix does include dependency tracking, in fact there's two different ways of installing software. It uses LILO which is a pain on multi disk or multi stage boots (use mbootpack). Easy to install, works quite well.
Alpine, Slackware/Salix, and Void are the closest you can get to FreeBSD in Linux-land. Debian GNU/kFreeBSD is an interesting experiment but I wouldn't recommend it.
In general:
Salix for the most BSD-like experience; very similar tools and philosophy. Uses OpenRC by default last I checked which is similar to FreeBSD rc, though FreeBSD doesn't have an equivalent to runlevels. Package manager spkg is less similar to FreeBSD pkg_ng and more similar to old-style BSD pkg_add and apt/dpkg in my opinion. It's the largest of all the choices I've said but that makes it feel more FreeKitchenSinkBSD eh?
Slackware if you're a masochist, since you aren't used to Linux. Salix just adds some nice user-friendly tools and modifications to Slackware and is backwards-compatible, so you should absolutely use it over vanilla.
Alpine if you like minimalism and/or non-GNU (userland is Busybox). Package manager apk is very straightforward and is closest to FreeBSD pkg_ng. Also uses OpenRC so the points for Salix I mentioned also apply here. I highly recommend it if you're wanting a system that will let you build your own environment while still remaining very user-friendly. I use it everywhere—servers, gateways, desktop, laptop, SoCs... Also it's tiny. Tiiiny.
Void is somewhere between Alpine and Salix; it's quite minimal but is much bigger than Alpine and doesn't have all the out-of-the-box features that Salix does. Feels more like Arch, including its package manager xbps that feels like some kind of frankenstein mush of pacman and apt/dpkg. I really don't like the package userland tools and they do not feel anywhere close to either pkg_ng or pkg_add. Additionally, it uses runit which while dead simple is nowhere near the robustness of FreeBSD rc or even OpenRC.
Since I'm an Alpine shill I recommend it first, but Salix is probably the "most BSD"; after all, Slackware has always been known for being the "most-Unix Linux" by a lot of people, since it's also the oldest distro still around, and it really hasn't changed much. You should try all of them to see what you like best.
I heard they might be switching to systemd a while ago, though... Hope that never happens.
And if you don't like any of them, install Gentoo.
If you miss /etc/rc.local (or /etc/rc.d/rc.local), then switch to a distro that is still sane. It's not exactly rocket surgery.
The previous 3 replies are all Linux distro's that don't use SystemD.
Since SystemD cannot run on windows at all, it's not a compatible windows app, then listing windows is irrelevant.
My point in listing Gentoo was because Devuan's claim to fame is that it is a SystemD-less distro, and from what I've seen it is being spruiked as such, However there are many distro's that don't use SystemD, which often seems lost in the SystemD Holy Wars.
You, listing windows, are just being a dick and not contributing at all to a useful argument: pointing out alternative linux distro's that support alternatives to SystemD.
"Since SystemD cannot run on windows at all, it's not a compatible windows app, then listing windows is irrelevant."
It's almost like...nah, it couldn't be, not in the comment section of elReg, but maybe, possibly...they were joking?
then it's a good suggestion, anything is better than using systemD from that poettering pillock, even "windows ME" would be better...
Now you have gone too far! It's pistols at dawn! I demand satisfaction - and you Sir, will be eating grass by lunchtime.
Oh God! The flashbacks! THE HORROR! The horror! The horror! ...
" Do you use the search field on Firefox's New Tab Page?"
That's a bridge too far for me. As much as I detest SystemD, I'd still take it over any version of Windows that I've ever used. SystemD brings in a lot of the sins that Windows commits, though, so in a sense it make Linux more Windows-like than I"m OK with.
Heh, I quoted something completely irrelevant to my comment, and nobody made fun of me? You guys are slacking!
Here's the quote I actually meant to include: "anything is better than using systemD from that poettering pillock, even "windows ME" would be better..."
I only just read your comment, and couldn't work out the context of the quote, and did even click on the wiggly arrow (technical term) to see the parent post, and scratched my head when I couldn't see where the original poster wrote about Firefox start menus, and started to question my sanity, and got reminded to take my pills, and then did so, then did so again, just to be sure, and I can see double rainbows, and now I just read your follow up post, and now i realise i'm not actually any more insane than usual, so instead, now I can laugh at you............
⏩⏩⏩⏩⏩⏩⏩⏩ Points at John and laughs! ⏩⏩⏩⏩⏩⏩⏩⏩⏩⏩⏩⏩
Slackware by itself with no dependency management is just a tad too painful, therefore Salix (LILO is also somewhat of a pain, may have to move to grub, or just be careful how its configured)
An over complex init system burdened with feature creep that affects other non Linux systems isn't appealing.
I'll grant that Arch Linux boots very fast indeed but I Don't Care. On my main system it takes probably a minute to even reach the boot loader, after its fiddled around with initialising peripherals, counting memory, and starting SAS controllers. On laptops once booted they're mostly suspended or hibernated, and restore is plenty fast enough for my needs.
> Agreed. I honestly don't understand why boot times are terribly important outside of a few edge use cases.
More to the point, when was it ever so slow that people were clamoring for a complete rewrite a-la systemd?
I mean, my Devuan distro on my ageing 4 core thinkpad boots so fast I barely notice. The longest delay in the boot process is the prompt for me to type in the disk decryption password.
Even before systemD, things booted quickly. Yes, back in the late 90s/early 2000s you could have slow booting as things are done one at a time, but I remember Gentoo supported parallel init script running in 2005 or so, and since then everything could do it.
The argument of "faster booting" of systemd was bogus before they foisted it upon the world, and in my experience systemD boots slower than my Devuan machine (it seems to like to hang on "waiting for..." type crap, for no reason I can fathom). It is also much harder to configure and debug. Lord only knows why they pushed is so hard, I suspect it was done deliberately so RedHat could make a mint offering support services (the Microsoft model of making money).
At work systemD has been such a PITA, that we decided to virtualise every single Linux machine, and now we just snapshot and rollback when systemd eventually shits the bed (which it does regularly). Thank god for Devuan (+others) and the BSDs that keep me sane at home.
If systemd wasnt such a clusterfuck and its arrogant ass of an author would just occasionally take some fucking advice from people who do have a few clues, we wouldnt keep going on about it until hopefully one day he bloody listens! New and different for the sake of being different != better.
And unfortunately the distros that dont use it are rarely sanctioned for corporate use. I use slackware at home but work is redhat all the way whether we like it or not.
...that this was never a change that should have been pushed by a minority of developers on a majority of users without adequate feedback and consultation. We had no voice or vote in this.
Since it was pushed in Redhat and Fedora, all other distros in their down chains were put in the awkward position of hard forking and committing a huge chunk of resources up front or constantly re-writing everything to make it work on on ongoing basis going forward. Most of the smaller distros don't have the manpower to waste. Most of the bigger ones had better things to do.
So, no don't tell me to use another Distro. That's like like my neighbor paving over my driveway and telling me to get another house.
It's not your lawn, so stop trying to kick other people off of it.
The problem isn't that it isn't usable at all ... the real problem is that, upon taking a look at it from the outside, bird's eye view, if you will, systemd is like that enormous, ugly, smelly monster out of the swamp. It runs fast though.
Just try getting rid of it, in a VM. Try to do it cleanly, with no traces.
Other inits have their love bites, but at least they "do one thing and do it well".
systemd tries to absorb the universe into it.
Hell, it even has a UEFI bootloader. WHY?!
"once you have the basics nailed it's loads better that init scripts"
I am pretty good at working with SystemD now, and I disagree.
"it's definitely not the rocket science"
That's true. My objection to it isn't the complexity in terms of using it. My objection is partly the complexity of its implementation, and mostly the fact that it does far, far more than it should in terms of replacing critical system components.
That's true. My objection to it isn't the complexity in terms of using it. My objection is partly the complexity of its implementation, and mostly the fact that it does far, far more than it should in terms of replacing critical system components.
If they really had to (in their minds) rewrite the init, they could've just stuck to effectively porting/rewriting SMF and stopped there. Still, at least wrangling with SMF one can think "it could be worse, it could be SystemD".
AFAIR this was Canonical's attempt to streamline startup & get dependencies sorted properly. It seemed to work on the earlier versions of Ubuntu & friends before the Systemd Blob sucked it in. Sad that Canonical felt they needed to follow the herd. I've had issues with systemd-resolved (doesn't do split DNS in my setup at all well, unlike dnsmasq), so I may well go the Devuan route when I get sufficiently pissed off.
Couldn't decide whether to upvote you for Yes, I will never forgive Debian for that. or downvote you for At least they still provide a means to avoid it, though. !
They don't provide a means to avoid it though - all that exists at the moment are few packages that won't work at all without it. Since systemd is the default, and supporting non-systemd systems is not mandated, over time it will get harder and harder to duct-tape a non-systemd Debian together.
That's why Devuan was born, to ACTIVELY maintain non-systemd package status - forking Debian packaging for those packages that need modifications, and providing replacement for a couple of irretrievably borged ones.
Yes, Devuan is the better solution, but Debian does provide shims that you can use to allow SystemD-dependent applications to run without SystemD being present. I have two such systems running right now (I haven't had the time to migrate them to a non-Debian distro yet).
To the comment above - unix doesn't reboot all the time....
It does in this fad world of a bunch of instances that are near-identical in the cloud, which business RedHat was making money on.
Of course, since it requires courses and consultants, the Reg is all for it - revenue, so they support this cloud fad thing themselves.
And all the related container/serverless/buzzword of the day junk that goes along, every now and then we need a new buzzword to sell the
same old "well, make it work for us, then" human services.
The swing back to mainframes, in essence. I've been around long enough to see the back and forth a few times now. Short attention span people don't see it.
Always follow the money, it's instructive. No way RedHat would have paid this loser and team to do this much major work if there wasn't that pot of gold perceived at the end of the rainbow.
Not that it's worked out for them - who would sell themselves to Big Blue if things were dandy? Oh yeah, people with a ton of not very liquid stock. Again, not that hard to follow...
I agree with your general point but, this, no:
> No way RedHat would have paid this loser and team to do this much major work if there wasn't that pot of gold perceived at the end of the rainbow.
Reason: you are assuming RedHat is rational.
I discovered RedHat had been completely hijacked by the corporate parasites over 5 years ago. This means they follow memes and internal coolnesses/emotion, rather than anything actually rational. Source: temp.flatmate worked there. Stories of utter madness, same as the big US corporates I'd worked in.
They were even then chucking out topspec machines (personal: laptops etc) just so people could have the newest shinyshiny.
I'm typing on one right now. Free. I keep the redhat sticker on it to remind me they've been hijacked.
"Unix doesn't reboot all the time."
In a properly run on-prem setup, that's right - it almost never needs to reboot.
However, with this new fad of cloud, and all that things that might entail, from tons of identical (or nearly) instances, containers, and the like, whatever the buzzword of the week is that sells the human service/conference for "well, now make it work for us", linux is forced to boot all the time.
Follow the money, it's often instructive. Red Hat was making a lot of its money off this cloud thing - the swing back to mainframes (again).
People make money selling ads for "buzzword of the week conference", present forum not excluded.
No way RedHat would have paid that clown and team all that money if they didn't perceive that pot of gold at the end.
But justice was served in a sense. No one sells themselves to IBM if things are all dandy, eh? Oh yeah, maybe people with a lot of stock they can't so easily sell without depressing the price....what was that we follow, again? $$$
Systemd suffers from many problems.
1) It was supposed to "replace all those shell scripts". And it did so. For some of them. With opaque C code that's vulnerable to all kinds of overflow and means you can't simply modify it without being a full-on programmer running a modified systemd binary.
2) It was supposed to "resolve all the dependency issues". Which it does... mostly. But via ways that basically require interpreting plain-text configuration files and spawning processes that could have been done in ANY language... including shell scripts. I see nothing that systemd does in this regard that a suitably intelligent single daemon couldn't manage without having to be tied into EVERYTHING. It uses new-kernel features to do some things like process groups, etc. but that's because they *didn't exist* in the kernel many years ago.
3) It tries to replace, rather than utilise or supplement, every service it touches. From "init dependency", it now replaces entirely your local DNS server, syslogging functionality, NTP, network interfaces, hardware detection, etc. and it just rides roughshod over everything, removes all your existing daemons and doesn't even try to do the rest of their jobs.
4) It replaces logging - in the same way that it replaces init/config... it could have just started with a backwards-compatible plain-text log-file but provided a tool that searches and filters them as per its current way of operating, without replacing the way EVERYTHING logs so that you can no longer just cat a log from /var/logs and expect it to be there, or contain the information you want, without going in and basically telling it to do so manually. And debugging what syslog itself is doing is a nightmare of filtering logs.
5) In the end... my computer used to boot up and work and be configurable and was pretty secure. Now it boots up (usually), works (usually), is pretty opaque (yes, I'm sure there's a way to "do" all those things, but it's nowhere near obvious) and is subject to things like vulnerabilities in a root-level binary process that doesn't drop privileges in order to do things like logging a multi-megabyte syslog message safely. Simple ways to add new startup services etc. are no longer simple, backward compatibility with old init configurations is gone, etc. I literally have no idea what it's going to do in what order any more. And it's literally no faster to boot or operate.
I see no problem that systemd "solved" (maybe some cloud-computing datacenter manager has something useful in there, for me as a mere mortal running networks and using a computer at home) - all it did was replace a system I could read and edit with one that I don't stand a chance of doing so without recompiling the equivalent of "init". For a problem that we could have solved in a bash script, while retaining backward compatibility until the natural advantages of it showed themselves.
As far as systemd is concerned - I just boot my distro. If it doesn't boot, or doesn't boot properly, then that's game over. I can do nothing. I don't see that as a plus in any way. In fact, it makes me nervous on every kernel or systemd upgrade that my distros put out. And I will back all problems in it back to the distro, whether by "not using it" or by making a fuss.
When we start getting root-level holes in these things because of simple things like "syslogging a large message" then it's really time to abandon it. Keep the config. Keep the syntax. Keep the same binary name, if you like (for compatibility - I never got why ipchains had to be replaced with iptables when you could have just made both be an alias to iptables which converted the older to the newer if it was ever invoked that way - and now it's no longer iptables either, and so on). Take "what systemd does" and get an equivalent that we can actually understand and use and fix easily.
I consider it a little like DBus and NetworkManager. Suddenly huge dependencies on DBus and X-Windows on everything you touch for no real reason, opaque and conflicting processes all trying to do simple things, and no way to really manage what's going on and instead you have to just "trust in the distro". Literally the core principle of open-source is out of the window not through closure of source, but through layers of obfuscation between the user and what the system is doing.
It wouldn't be so bad if it was a tiny collection of small utilities, one per job, that were replaceable and auditable, but it's now hundreds of thousands of lines of C.
@Lee - Precisely from me too.
Now that there even IS a man page for systemd...wow. Back when it was breaking things like boot time mounts of NFS filesystems in /etc/fstab, I looked for some workaround on the 'net and found that you could make a .mount thing - that worked for about 2 distro updates (not upgrades) before the workaround was broken by a fix to an issue that originally had an E_WONTFIX tag...and now NFS mount in fstab works again.
I just checked the man page that now exists. To be sure, the usual bafflegab and when you have to link to a website, you've already failed. I note that no where in the "see also" 'is the name of the manpage you really need if you're customizing a desktop or other on-prem specialized machine -
sysd_service_file
Now, being that just about zero other man pages even have underscores in the name...how again was I supposed to guess that one?
How about if some daemon takes too long to start and systemd starts it over and over again without killing the previous attempt till the system goes down, as it did with Conky?
How about becoming unable to reboot if something mentioned in fstab can't be unmounted because it was never mounted due to another bug, or because someone manually unmounted it. I bet people who have to drive to a site to fix that got real happy.
Could some of the hostility be due to breaking things, and then breaking the workarounds, all while not ever admitting there was a problem in the first place?
Sorry about the double post above - the site said something messed up so I typed things in a second time.
The choice of C is very peculiar. For a load of non-kernel root code handling critical data doing important jobs, picking a language where it's far harder to make mistakes with memory usage / handling would be less peculiar, eliminating a whole class of cock ups from the project.
Rust, anyone?
... something like this was going to happen when SystemD was shoved down Linux users' throats? This what you expect to eventually happen when you ignore the rule of doing one thing and doing it well. Sure... "doing it well" is in the eye of the beholder but going to "one thing that does everything" was bound to eventually fail.
Sure, Chuck. But well made things last well past their sell-by-date. For example, as I was canning this last year's tomatoes I noted that over 6 dozen of my Mason/Ball jars are over 80 years old. Some are over a century old.
SysV and BSD inits, like Mason and Ball jars, still work perfectly well. Insisting on babykitsystemd is kind of like requiring users to install a modern canning line to put up a few quarts of tomatoes, with all the long-term headaches that that entails.
I like systemd, makes what I do easier. It has its problems but I wouldn't go back to the past despite them. Patching is something you've got to do monthly if not more frequently anyway, the bug is in systemd or outside of, makes little difference. Adopting Devuan or Slackware or BSD or something is like cutting off your hands because you're tired of trimming your nails every so often. Not anon for this, smash that downvote button if it makes you feel better.
>Some of us, have enough real work (TM) to justify our ongoing existence.
Like porting python software to windows. I much rather do SystemD than service wrappers which needs a hack like nssm.exe, or navigating around with event logger. If there was SystemD on windows it would be a great improvement.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
