Systemd 254 released, deprecating sysvinit scripts(lwn.net)
lwn.net
Systemd 254 released, deprecating sysvinit scripts
https://lwn.net/Articles/939511/
124 comments
I get the criticism which essentially boils down to, it's turning what used to be a "bazaar" into a "cathedral". Instead of the init system, udev, dbus, logging, networking, dhcp, run levels, cron, login system, etc. being separate systems bound together with duct tape, they're now one coherent system layer called systemd. I personally really like that, but I get why others wouldn't.
I don't get the outrage here about this decision though. If you were relying on systemd's sysvinit script support, you were already using systemd. And systemd .service files are strictly better than sysvinit scripts if you're already running systemd.
I don't get the outrage here about this decision though. If you were relying on systemd's sysvinit script support, you were already using systemd. And systemd .service files are strictly better than sysvinit scripts if you're already running systemd.
Most people complaining about systemd wouldn't even notice if their whole OS was just a single binary.
This attitude does not help the Linux stack, because the one thing software vendors do not have time for is to test against 10+ init systems[1].
I don't need both Wayland and X11, I just need one of these that is reliable.
I also don't need both Flatpak and Snap, I just need only one that does not have crippling bugs.
I also do not want to care about what version of glibc is on the target machine, I just want to compile a blob that anyone using any distro can run.
Choice is good, however not when it comes to the base system, the base system needs to be there and it needs to be reliable and people should build good stuff on top of that, init systems are not exciting things to build.
[1] https://wiki.gentoo.org/wiki/Comparison_of_init_systems
This attitude does not help the Linux stack, because the one thing software vendors do not have time for is to test against 10+ init systems[1].
I don't need both Wayland and X11, I just need one of these that is reliable.
I also don't need both Flatpak and Snap, I just need only one that does not have crippling bugs.
I also do not want to care about what version of glibc is on the target machine, I just want to compile a blob that anyone using any distro can run.
Choice is good, however not when it comes to the base system, the base system needs to be there and it needs to be reliable and people should build good stuff on top of that, init systems are not exciting things to build.
[1] https://wiki.gentoo.org/wiki/Comparison_of_init_systems
That's all perfectly fine and a perfectly understandable attitude.
The thing is, it's not really what Linux is about, or FOSS or plain old human nature.
Different people like different things. They want choice and the same choices don't work for everyone. If you have a whole group of Unix computer users all hacking away on what they like and they want, you get diversity and options.
So that means that there are lots of types of Linux with different choices and tools. That's a good thing. It's one of the things I like about Linux.
If you want the one best choice for everything, the democratically-arrived at moderate sensible path of compromise, then go try FreeBSD, which does that but also embraces modern commodity hardware. You still get a wide choice of desktops and things, but much less wide.
But the choices of FreeBSD didn't suit everyone, and as a result there are also OpenBSD and NetBSD and DragonflyBSD and a lot of divided effort that results in slow overall progress.
Me, I am old and grumpy and I want stuff that Just Works™. So, because I can afford it, my home desktop is an iMac, because by and large, macOS Just Works.
But I dislike Apple's modern keyboards, and pointing devices, and lack of ports, and a lot of other things about their laptops. So I use Linux laptops. And there, I do not find that systemd helps me... but the mainstream distros all use it so I just put up with it. And it keeps making my machines fail to boot randomly, and it's not getting any better.
I keep eyeing up distros without it and stroking my greying beard thoughtfully, though.
The moral here is that there isn't, and can't be, One Best Option that suits everyone. It's not possible because different people want different things.
The thing is, it's not really what Linux is about, or FOSS or plain old human nature.
Different people like different things. They want choice and the same choices don't work for everyone. If you have a whole group of Unix computer users all hacking away on what they like and they want, you get diversity and options.
So that means that there are lots of types of Linux with different choices and tools. That's a good thing. It's one of the things I like about Linux.
If you want the one best choice for everything, the democratically-arrived at moderate sensible path of compromise, then go try FreeBSD, which does that but also embraces modern commodity hardware. You still get a wide choice of desktops and things, but much less wide.
But the choices of FreeBSD didn't suit everyone, and as a result there are also OpenBSD and NetBSD and DragonflyBSD and a lot of divided effort that results in slow overall progress.
Me, I am old and grumpy and I want stuff that Just Works™. So, because I can afford it, my home desktop is an iMac, because by and large, macOS Just Works.
But I dislike Apple's modern keyboards, and pointing devices, and lack of ports, and a lot of other things about their laptops. So I use Linux laptops. And there, I do not find that systemd helps me... but the mainstream distros all use it so I just put up with it. And it keeps making my machines fail to boot randomly, and it's not getting any better.
I keep eyeing up distros without it and stroking my greying beard thoughtfully, though.
The moral here is that there isn't, and can't be, One Best Option that suits everyone. It's not possible because different people want different things.
To me that's the proper evolution. As knowledge of a problem matures, it makes sense to mash the best-practices together into a single monolith that's designed to work together with minimal bubble-gum. The Cambrian explosion of small tools makes sense early-on but the cognitive load of that approach is much higher, and some of us have crap to do.
I wish there was a command to just generate one of these files instead of always having to look it up, copy/paste, and then fill it all in.
It's the simple things that reduce friction that matter. Devs never understand this.
It's the simple things that reduce friction that matter. Devs never understand this.
Some people don't want simple and comprehensible. They want to run unnecessarily complex scripts in black terminals with green fonts. Let them be, somebody has to operate all the remaining PHP web pages out there.
To be fair, after reading the thread about how people are voting with their feet about systemd-based distributions, I think there's a fair bit of trolling in this thread.
"Dropping systemd" would mean that they either use containers in an OS that most likely uses systemd itself, or they otherwise use some niche distribution (such as Antix, Devuan) that I've never heard of being used widely in a production context.
Other aspects of systemd might need getting some used to, but it's nothing that a reading of the Archlinux wiki didn't solve.
"Dropping systemd" would mean that they either use containers in an OS that most likely uses systemd itself, or they otherwise use some niche distribution (such as Antix, Devuan) that I've never heard of being used widely in a production context.
Other aspects of systemd might need getting some used to, but it's nothing that a reading of the Archlinux wiki didn't solve.
Voting with their feet? As a non-OS developer, I have a very limited distribution selection if I want to use a popular choice receiving more support , bug fixes, etc. Sure, I could run a less popular distribution that foregoes systemd, but what happens when I encounter an issue with wifi, sound, etc. Can I get CUDA or Steam to work on a periphery OS?
Systemd is chosen for me because there is so much more to an OS.
Systemd is chosen for me because there is so much more to an OS.
It is chosen for you democratically by people that actually bother fixing those problems for you, for mostly free. Debian has voted multiple times on it, with systemd winning hands down each time.
Maybe we should listen to their expertise, shouldn’t we?
Maybe we should listen to their expertise, shouldn’t we?
[deleted]
> It couldn't really be any simpler.
It could. Ask ChatGPT4 for a bash script that writes the unit for you into the right place.
Colossal amounts of drudgery, all suddenly gone. The problem was never the opinions for how things were done, it was always the drudgery of reading documentation. Now, poof.
It could. Ask ChatGPT4 for a bash script that writes the unit for you into the right place.
Colossal amounts of drudgery, all suddenly gone. The problem was never the opinions for how things were done, it was always the drudgery of reading documentation. Now, poof.
I really cannot believe how much worse HN comments have got over the past few years, from an already pretty annoying point.
just...wow.
just...wow.
I don’t know dude, did you try it? I’ve done exactly this, have it do the drudgery of writing the unit, I am a sophisticated developer. I am just trying to share a different POV, that the controversy over so many tools is really about how weird or wonky they are to use. But if the interface for them becomes simple and expressive, suddenly those complaints don’t matter. It goes from “just” and “simply” to just and simply, which is incredible. And if you still don’t know what I’m talking about, if you still feel like downvoting or saying what the other commenters say…
Listen, it’s $20 to find out if what I’m saying is true. Just try it.
Listen, it’s $20 to find out if what I’m saying is true. Just try it.
I guess a (yet another) noticeable downturn happened at the Reddit exodus.
If we're going to use the "just use GPT" response, you could ask ChatGPT for a systemd unit.
Also, this completely ignores the fact that GPT4 will often make up functions or make incorrect assumptions about how a language feature works (and I've seen it make several mistakes wrt shell quoting and the like), making it unusable for writing production code when you don't know the domain yourself. If you now have to debug the script, the use case of LLMs is gone.
Also, this completely ignores the fact that GPT4 will often make up functions or make incorrect assumptions about how a language feature works (and I've seen it make several mistakes wrt shell quoting and the like), making it unusable for writing production code when you don't know the domain yourself. If you now have to debug the script, the use case of LLMs is gone.
> Ask ChatGPT4 for a bash script that writes the unit for you into the right place. Colossal amounts of drudgery, all suddenly gone.
Given that humans can't write reliable bash scripts that don't randomly delete things in your computer [1], why would you expect something generated by LLMs to not randomly delete things on your computer or worse?
If you have to inspect and debug whatever the AI generated, that is potentially a lot worse that just writing it yourself in the first place.
[1] https://github.com/MrMEEE/bumblebee-Old-and-abbandoned/issue...
Given that humans can't write reliable bash scripts that don't randomly delete things in your computer [1], why would you expect something generated by LLMs to not randomly delete things on your computer or worse?
If you have to inspect and debug whatever the AI generated, that is potentially a lot worse that just writing it yourself in the first place.
[1] https://github.com/MrMEEE/bumblebee-Old-and-abbandoned/issue...
discussions like this are good reminders of how low quality most HN threads are. a huge mass of random whinging about the people involved, non-technical whinging about imagined architecture decisions (like "systemd is a monolith") and then conspiracies about Microsoft like it's a slashdot thread in 1998.
notably missing:
- discussions about how fucking shit PID files and things like start-stop-daemon are or how annoying it was writing a sh script for every daemon, or how in sysvinit things can become un-shut-downable
- discussion about how making containerisation/chroot/resource limits trivial is good actually
- reflections on how hard making a reliable good init system is, cf upstart/launchd/whatever solaris had and how nice it is that someone actually did it for linux
etc etc
notably missing:
- discussions about how fucking shit PID files and things like start-stop-daemon are or how annoying it was writing a sh script for every daemon, or how in sysvinit things can become un-shut-downable
- discussion about how making containerisation/chroot/resource limits trivial is good actually
- reflections on how hard making a reliable good init system is, cf upstart/launchd/whatever solaris had and how nice it is that someone actually did it for linux
etc etc
I would add
- making handling of forking to the background and log rotation not a task of the program itself, instead of making every program (or worse, a bespoke wrapper shell script) do it.
Because such things are non-trivial and demand reasonably many man-hours of otherwise "trivial" projects.
Granted, you don't actually need systemd to do such things (for example, runit can do such things, and runit is available under busybox and therefore almost universal in most GNU/Linux distros), but I think it was systematic distro/systemd that enforced such new paradigm.
- making handling of forking to the background and log rotation not a task of the program itself, instead of making every program (or worse, a bespoke wrapper shell script) do it.
Because such things are non-trivial and demand reasonably many man-hours of otherwise "trivial" projects.
Granted, you don't actually need systemd to do such things (for example, runit can do such things, and runit is available under busybox and therefore almost universal in most GNU/Linux distros), but I think it was systematic distro/systemd that enforced such new paradigm.
I think systemd is quite good.
For those who doesn’t like it: There are other service managers out there. IMHO the most sophisticated alternative is s6-rc.
It runs on both Linux and *BSD.
https://skarnet.org/software/s6-rc/
For those who doesn’t like it: There are other service managers out there. IMHO the most sophisticated alternative is s6-rc.
It runs on both Linux and *BSD.
https://skarnet.org/software/s6-rc/
Instead of complaining just drop anything that contains Systemd. I did and my frustration with IT related tasks has gone way down.
I agree although I still run systemd. I run both Debian (with systemd) and Devuan (a Debian fork with anything systemd removed). The reason I still run a systemd-less fork is to not forget that Linux still works fine without systemd.
Linux is not systemd.
I did actually write systemd services and I'm not sure the "convenience" warrants what Microsoft (and Poettering) are doing to Linux.
The only one true savior we still have is Linus and, so far, Poettering still hasn't found a way to control the kernel's development.
But Microsoft/Poettering already won PID 1 on most distros/installs and, although I run systemd on several machines (including servers), it is not good that PID 1 is lost. It simply isn't.
Even if there were no technical objections (but there are: gigantic attack surface, lame binary logs, bugs regularly tagged as "not bugs" because Poettering feels like they're not bugs, etc.), it's still a huge problem how this gigantic squid spreads its tentacle everywhere.
Anyone finding it totally normal that the person in charge of PID 1 works for Microsoft is totally delusional.
People should at least acknowledge there are reasons to be concerned about that.
And whether sysvinit scripts do actually suck or not has nothing to do with PID 1 being controlled by someone working for Microsoft.
Linux is not systemd.
I did actually write systemd services and I'm not sure the "convenience" warrants what Microsoft (and Poettering) are doing to Linux.
The only one true savior we still have is Linus and, so far, Poettering still hasn't found a way to control the kernel's development.
But Microsoft/Poettering already won PID 1 on most distros/installs and, although I run systemd on several machines (including servers), it is not good that PID 1 is lost. It simply isn't.
Even if there were no technical objections (but there are: gigantic attack surface, lame binary logs, bugs regularly tagged as "not bugs" because Poettering feels like they're not bugs, etc.), it's still a huge problem how this gigantic squid spreads its tentacle everywhere.
Anyone finding it totally normal that the person in charge of PID 1 works for Microsoft is totally delusional.
People should at least acknowledge there are reasons to be concerned about that.
And whether sysvinit scripts do actually suck or not has nothing to do with PID 1 being controlled by someone working for Microsoft.
Poettering didn't join Microsoft until 2022, systemd has been around since 2010.
True, but soon he will be dropping script integration, not that I care, but the coincidence is a interesting. Join M/S, drop shell scripts :)
Script integration is not dropped. You can easily run a script from a unit file.
Yea, they're dropping the native generator for /etc/init.d, I believe. Scripts placed here implicitly became systemd services.
Nothing of huge value is lost. Distributions play an important part, we shouldn't forget. They can maintain something like this for users, if so inclined.
This mostly hurts third party/ancient/naive packages that you probably, eventually, won't want to install on your distribution for other reasons.
This won't affect any packages natively provided by your distribution of choice. Think those random RPMs/DEBs you get from an external vendor -- UPS, keyboard, whatever.
They've had over a decade to see the writing on the wall, adding ~12 lines to their entire codebase/packaging spec. Probably a net-reduction given the NIH-syndrome of these scripts.
Instead, I've seen them make this directory, put their scripts inside, and just expect things to work out. It did, arguably by chance. The compatibility was deliberate, but support isn't forever.
Nothing of huge value is lost. Distributions play an important part, we shouldn't forget. They can maintain something like this for users, if so inclined.
This mostly hurts third party/ancient/naive packages that you probably, eventually, won't want to install on your distribution for other reasons.
This won't affect any packages natively provided by your distribution of choice. Think those random RPMs/DEBs you get from an external vendor -- UPS, keyboard, whatever.
They've had over a decade to see the writing on the wall, adding ~12 lines to their entire codebase/packaging spec. Probably a net-reduction given the NIH-syndrome of these scripts.
Instead, I've seen them make this directory, put their scripts inside, and just expect things to work out. It did, arguably by chance. The compatibility was deliberate, but support isn't forever.
That’s wild! I too have seen horror I wish I could forget.
For those still worried, the pain is limited to about 15 minutes of writing a unit file, testing it, and waiting for ci or builds to finish!
I expect to have to do this for older or more esoteric stuff, but I also enjoy writing unit files.
For those still worried, the pain is limited to about 15 minutes of writing a unit file, testing it, and waiting for ci or builds to finish!
I expect to have to do this for older or more esoteric stuff, but I also enjoy writing unit files.
What a shit take.. system boot is a complex problem requiring a monolith solution, otherwise you just building some Rube Goldberg machine. The same way the kernel is a fucking huge monolith.
Also, what would be the point with Poettering? What does he gain from being constantly criticized by lunatics? Like honestly, these takes are some jewish space laser level ones.
Also, what would be the point with Poettering? What does he gain from being constantly criticized by lunatics? Like honestly, these takes are some jewish space laser level ones.
I've ported dozens of services many production critical over to SystemD over several companies. The only thing I've ever had issue with is systemd-timesyncd. Otherwise, its been rock solid. What the hell are you doing that gives you so much trouble with SystemD
Ditto, much success with systemd here.
The 'overreach' people complain about exists for a good reason. Services need mounts/networks/etc to actually do their job reliably.
If people could discard the 'nyeh' sentiment, use recent releases, and actually engage with the system, they can only find more reliability.
What was once tailored in scripts for each service/job/whatever is now provided by the system
It's about clearly laying out dependencies. Not a lot more.
The only bad experience I've had with systemd is on Ubuntu 18; where I've been forced at work. It's common for systemctl daemon-reexec to be needed, to resuscitate it. It's woefully far behind.
The 'overreach' people complain about exists for a good reason. Services need mounts/networks/etc to actually do their job reliably.
If people could discard the 'nyeh' sentiment, use recent releases, and actually engage with the system, they can only find more reliability.
What was once tailored in scripts for each service/job/whatever is now provided by the system
It's about clearly laying out dependencies. Not a lot more.
The only bad experience I've had with systemd is on Ubuntu 18; where I've been forced at work. It's common for systemctl daemon-reexec to be needed, to resuscitate it. It's woefully far behind.
18.04 is EOL! unless they're paying for that extended support, it's time to upgrade
I should've probably mentioned this, but we've got that covered! ESM until we can finish our move to the New Home
I appreciate the mention though, never know how long people intend to keep things running.
I appreciate the mention though, never know how long people intend to keep things running.
[deleted]
Huh. Since learning more about systemd my frustration with IT related tasks has gone way down.
Unit files are far more functional for the same amount of effort as SysV scripts.
Unit files are far more functional for the same amount of effort as SysV scripts.
beyond init and udev script cobbling, I've recently plunged deep into networkd and resolved for the heck of it, discovered networkctl and resolvectl in the process, and it's been a very pleasant experience so far, making easy things trivial and hard things easy.
It really has made things much easier after a slightly frustrating knowledge speed bump.
Unit files seem like a good idea. Does systemd need to do everything it does in order to gain that benefit?
Yes? People don't realize that systemd is a project, and systemd the init system isn't journald or systemd-boot or systemd-resolved. Those are other compatible utilities by the same project. They aren't required to use systemd itself.
Many of the systemd components are separate and optional. You can easily eschew from systemd-timesyncd and systemd-resolved, for example.
Not entirely, for example:
Units can depend on networking managed outside of systemd-networkd using the target -- think of this as a 'run level'
Units can depend on mounts outside of systemd .mount units -- there's a generator that considers fstab
At a certain point, you might want to go further into systemd... but it doesn't require it.
The basic 'this service wants/needs these other ones' is very self-contained, and inherits a lot.
Units can depend on networking managed outside of systemd-networkd using the target -- think of this as a 'run level'
Units can depend on mounts outside of systemd .mount units -- there's a generator that considers fstab
At a certain point, you might want to go further into systemd... but it doesn't require it.
The basic 'this service wants/needs these other ones' is very self-contained, and inherits a lot.
[deleted]
Yes. It needs to know what mounts and networks are needed for my various services. It needs to be sure the system is synced with NTP before moving past a certain point. And so on.
I took the opposite route, accepting defeat and embracing systemd. My purist self doesn’t like it, but my pragmatic self is happy and cannot be bothered by all the people complaining about it.
I find systemd amazing, and worlds better than sysvinit. I'll be happy to never admin a sysvinit box again!
I don't know how I feel about the implication that sysvinit ever did something that could be called "working".
I'm curious what alternative you make use of.
My issue has been that getting an alternative set up was just painful enough that the related learning doesn't fit into a very full schedule.
My issue has been that getting an alternative set up was just painful enough that the related learning doesn't fit into a very full schedule.
What kind of frustrations has systemd caused you? I know there are a lot of very valid criticisms of it, but the only time I’ve experienced actual frustration is when I’m fighting with the timer syntax that I can never seem to memorize.
Besides Nix, it’s the easiest way I’ve found to declaratively define a system that just works.
Besides Nix, it’s the easiest way I’ve found to declaratively define a system that just works.
I would also have no IT related problems if my computer wouldn’t boot..
Can we all just take a moment to laugh at the fact that all of this complexity is, roughly speaking, the evolution of AUTOEXEC.BAT?
(Pedants: I know AUTOEXEC.BAT not a direct ancestor of systemd, but it's a close cousin and serves the same purpose: run stuff when you boot.)
(Pedants: I know AUTOEXEC.BAT not a direct ancestor of systemd, but it's a close cousin and serves the same purpose: run stuff when you boot.)
That's not really fair. systemd does a lot more, and with good reason (among other reasons: there are many, many economies that can be made when "booting" and "managing" services happens in the same hat)
>That's not really fair
Uh, what? It's not fair to say that a vastly more complicated thing evolved from a simple thing? That's how it always happens - each step seems reasonable, and justified, but you look at what those countless rational decisions added up to, and bam. That's the complexity everyone says they hate. In technology, in government, in basically everything.
(Oddly, culture seems to be okay deprecating old bits of culture; the brain is inherently finite so we run in cycles and epicycles of cultural fashion that remains roughly at the same level of complexity.)
Uh, what? It's not fair to say that a vastly more complicated thing evolved from a simple thing? That's how it always happens - each step seems reasonable, and justified, but you look at what those countless rational decisions added up to, and bam. That's the complexity everyone says they hate. In technology, in government, in basically everything.
(Oddly, culture seems to be okay deprecating old bits of culture; the brain is inherently finite so we run in cycles and epicycles of cultural fashion that remains roughly at the same level of complexity.)
what a weird take - the "complexity" of sysv has to include the random shell scripts people write for /etc/init.d of hugely variable quality, and the tooling like start-stop-daemon, and the administrative complexity of not actually being able to reliably shut down (needs a process group) or start up service (needs dependencies).
it is much simpler for some people to write a dependency-based init system and then for my OS to write dependencies for the OS services then for me to say "DependsOn = network.service" to permanently avoid racing dhcp or whatever.
it is much simpler for some people to write a dependency-based init system and then for my OS to write dependencies for the OS services then for me to say "DependsOn = network.service" to permanently avoid racing dhcp or whatever.
Turns out launching something isn't enough, these days - interdependence, and all.
Took some decades to collectively get tired enough to decide on a language to declare it
Took some decades to collectively get tired enough to decide on a language to declare it
I want my cake and it to boot fast too.
I saw that very often but I run a very lean Devuan (a Debian fork without systemd) and it boots ultra-fast too.
Machines and especially SSDs have gone a long way since ten years ago and people think Linux boots fast "thanks to systemd"... But I'd encourage these people to install Devuan just to give it a try. It may boot a tiny bit slower than Debian (for an identical system) but it's still very quick.
Put it in another way: the savings systemd did brought regarding booting times in 2015 aren't looking anywhere near as impressive today. I don't even know: on my 7700X I think from boot (since the moment I enter the disk decryption password) to (text mode) login prompt it take about a second under Debian (systemd)? Maybe it takes 1.5 seconds running Devuan (non-systemd)?
I mean: 20 seconds instead of 45 seconds may have seen like a bit saving in 2015 but 1 second vs 1.5 second, I don't give a rat's arse.
And people who really need super fast boot times in containers shall use Alpine without systemd anyway.
Machines and especially SSDs have gone a long way since ten years ago and people think Linux boots fast "thanks to systemd"... But I'd encourage these people to install Devuan just to give it a try. It may boot a tiny bit slower than Debian (for an identical system) but it's still very quick.
Put it in another way: the savings systemd did brought regarding booting times in 2015 aren't looking anywhere near as impressive today. I don't even know: on my 7700X I think from boot (since the moment I enter the disk decryption password) to (text mode) login prompt it take about a second under Debian (systemd)? Maybe it takes 1.5 seconds running Devuan (non-systemd)?
I mean: 20 seconds instead of 45 seconds may have seen like a bit saving in 2015 but 1 second vs 1.5 second, I don't give a rat's arse.
And people who really need super fast boot times in containers shall use Alpine without systemd anyway.
AUTOEXEC.BAT is same thing as a sysvinit script.
COMMAND.COM is a far more closer “relative” to SystemD than AUTOEXEC.BAT.
Previous discussion: https://news.ycombinator.com/item?id=36513889
General question: what do most people here dislike about systemd now? Binary logs? Logind? I mean this out of general curiosity. I’ve used systemd a fair amount and I don’t really fight it, but I’m not in love with it or anything.
I am not sure and I have used systemd through NixOS in particular for a good half a decade now. While I have not tried to fight it, it does come across as being somewhat opaque to me, but I can generally deal with it and have not gone out of my way to “read a book” on it. It did annoy the hell out of me about a month ago when I had this “conversation” with it:
> sudo reboot
[sudo] password for ninjin:
Failed to reboot system via logind: Connection timed out
> sudo halt
Failed to set wall message, ignoring: Connection timed out
Failed to reboot system via logind: Connection timed out
Try `sudo systemctl reboot`. I've run into that issue in the past and somehow that worked.
On Fedora 37 `reboot` is `/usr/sbin/reboot` which is a symlink pointing to `/usr/bin/systemctl` so I don't know why it would matter, but I'll chalk it up to FM
On Fedora 37 `reboot` is `/usr/sbin/reboot` which is a symlink pointing to `/usr/bin/systemctl` so I don't know why it would matter, but I'll chalk it up to FM
> what do most people here dislike about systemd now
Microsoft / Poettering controlling PID 1 development. As simple as that.
It could be better on technical merits (I'm 100% convinced systemd ain't the be-all end-all of init/services scripts / PID1 though), I still hate Poettering's attitude. And that guy proved all the haters right by going to work for Microsoft: it's the ultimate fuck you to people who believed in Linux since the beginning.
Microsoft / Poettering controlling PID 1 development. As simple as that.
It could be better on technical merits (I'm 100% convinced systemd ain't the be-all end-all of init/services scripts / PID1 though), I still hate Poettering's attitude. And that guy proved all the haters right by going to work for Microsoft: it's the ultimate fuck you to people who believed in Linux since the beginning.
> And that guy proved all the haters right by going to work for Microsoft: it's the ultimate fuck you to people who believed in Linux since the beginning.
I'm sure Lennart was thinking about maximizing tribal offense while evaluating his stable employment options in the midst of RedHat's obvious decline.
The list of employers for a full-time upstream systemd maintainer at a competitive salary is rather short. And none of them are particularly attractive in terms of how dirty you'll feel having their logo on your paychecks.
I'm sure Lennart was thinking about maximizing tribal offense while evaluating his stable employment options in the midst of RedHat's obvious decline.
The list of employers for a full-time upstream systemd maintainer at a competitive salary is rather short. And none of them are particularly attractive in terms of how dirty you'll feel having their logo on your paychecks.
> and that guy proved all the haters right by going to work for Microsoft: it's the ultimate fuck you to people who believed in Linux since the beginning.
er...what on earth are you talking about?
as far as I recall, people complained about Lennart because:
1. they didn't like his attitude (lol)
2. they didn't want "init" to do so much, which was mostly just people not bothering to actually look into systemd-the-binary vs systemd-the-project was
3. random specific technical complaints like journald not using plain text or unit files being ini files or whatever
edit: typo
> it's the ultimate fuck you to people who believed in Linux since the beginning.
out of interest, when in the 90's do you feel this was?
does it only apply to people who used slackware 1.0? or just SLS users? or does one have to have received a tarball from Lars directly?
er...what on earth are you talking about?
as far as I recall, people complained about Lennart because:
1. they didn't like his attitude (lol)
2. they didn't want "init" to do so much, which was mostly just people not bothering to actually look into systemd-the-binary vs systemd-the-project was
3. random specific technical complaints like journald not using plain text or unit files being ini files or whatever
edit: typo
> it's the ultimate fuck you to people who believed in Linux since the beginning.
out of interest, when in the 90's do you feel this was?
does it only apply to people who used slackware 1.0? or just SLS users? or does one have to have received a tarball from Lars directly?
I don't mind it now, but in the earlier days it was pretty buggy.
Now I'm just at the "minor annoyance" stage as I don't do admin stuff much anymore, and I have to google stuff that used to be easy when I need to do something.
eg. in the past you could just type /etc/init.d/something <press tab> and it would show you services matching that prefix.
For logs, you could just go "cd /var/log && egrep blah *" to look for something.
Now of course I could write some wrapper functions for that using fzf or whatever to make life easy, but that's not always viable if you manage a fleet of hosts with restrictions where you don't have your custom bash profile and required utilities installed.
Now I'm just at the "minor annoyance" stage as I don't do admin stuff much anymore, and I have to google stuff that used to be easy when I need to do something.
eg. in the past you could just type /etc/init.d/something <press tab> and it would show you services matching that prefix.
For logs, you could just go "cd /var/log && egrep blah *" to look for something.
Now of course I could write some wrapper functions for that using fzf or whatever to make life easy, but that's not always viable if you manage a fleet of hosts with restrictions where you don't have your custom bash profile and required utilities installed.
OpenRC does most of the stuff that systemd does but better, and has existed for longer.
SystemD is architected in a way that makes significant security issues all but inevitable. There's just too much code running in PID 1 to be able to audit, too big of an attack surface.
Binary logs are frankly pretty annoying, but probably really helpful if you're in a large enterprise environment.
Locality of behavior is another annoyance, some services require a bunch of unit files to work well. One `.service`, another `.socket`, maybe a timer. There are also something like 6 different locations a unit file can live, depending on how it was installed, who owns it, etc. This is once again great for enterprise customers but means that if you want to find a unit file you can't just look in a directory, maybe a users home dir if it's a user service. You have to memorize or look up the systemd command that tells you where the unit files actually is. Same problem with unit file overrides. Overrides aren't just `myunit.service.override` or something next to your service, they live in their own folder and you need to use systemd commands to find/edit them.
Basically it discourages general unix knowledge in favor of memorizing a huge number of systemd specific commands, it does this by hiding files all over the place, using binary logs, and otherwise going out of their way to make themselves incompatible with unix-as-a-programming-environment.
They also make controversial decisions that you're probably shielded from by your distro, things like killing long-lived tmux sessions. Changing the behavior of your lid switch with no warning. They break a lot of stuff and when they do they're very unsympathetic about it. I recognize that they get a lot of hate, but when I look at issue trackers I often see people on the SystemD side being unprofessional first and escalating minor disagreements.
Can't launch systemd services in a chroot either, you need to be running systemd as pid 1 on your host system if you want to work with any kind of embedded linux that uses systemd.
SystemD is architected in a way that makes significant security issues all but inevitable. There's just too much code running in PID 1 to be able to audit, too big of an attack surface.
Binary logs are frankly pretty annoying, but probably really helpful if you're in a large enterprise environment.
Locality of behavior is another annoyance, some services require a bunch of unit files to work well. One `.service`, another `.socket`, maybe a timer. There are also something like 6 different locations a unit file can live, depending on how it was installed, who owns it, etc. This is once again great for enterprise customers but means that if you want to find a unit file you can't just look in a directory, maybe a users home dir if it's a user service. You have to memorize or look up the systemd command that tells you where the unit files actually is. Same problem with unit file overrides. Overrides aren't just `myunit.service.override` or something next to your service, they live in their own folder and you need to use systemd commands to find/edit them.
Basically it discourages general unix knowledge in favor of memorizing a huge number of systemd specific commands, it does this by hiding files all over the place, using binary logs, and otherwise going out of their way to make themselves incompatible with unix-as-a-programming-environment.
They also make controversial decisions that you're probably shielded from by your distro, things like killing long-lived tmux sessions. Changing the behavior of your lid switch with no warning. They break a lot of stuff and when they do they're very unsympathetic about it. I recognize that they get a lot of hate, but when I look at issue trackers I often see people on the SystemD side being unprofessional first and escalating minor disagreements.
Can't launch systemd services in a chroot either, you need to be running systemd as pid 1 on your host system if you want to work with any kind of embedded linux that uses systemd.
Personally I'm much more annoyed by taking control of how I partition my fucking drives.
Yes, I know why. IBMHat makes me like FreeBSD more with every power grab.
Yes, I know why. IBMHat makes me like FreeBSD more with every power grab.
How does it do that?
It has great optional support for Discoverable Partitions, which has made writing custom kernel cmdline's optional. https://uapi-group.org/specifications/specs/discoverable_par...
Systems is also are deprecating non merged-/usr.
Systems is also are deprecating non merged-/usr.
By making Linux less attractive to me.
I meant, how does it dictate partition layout/xxx?
It doesn't. If you are using GPT instead of MBR partitioning, AND you use particular partition type UUIDs that SystemD has reserved, THEN you can skip creating an /etc/fstab, and systemd will be able to mount the partitions where their type IDs indicate. If you do choose to create an /etc/fstab that will override the partition type IDs.
Is there a good systemd book to learn it all?
It has a very good manual. Lennart's blog also has a series named systemd for Administrators: https://0pointer.de/blog/projects/systemd-for-admins-1.html
I have answered all my systemd questions with the manual/manpage.
The systemd man pages are really great. Red Hat may not be perfect but they do a really good job with documentationj. I was shocked (in a good way) with how good the NetworkManager man pages are, among some others.
If you're learning something new, it's definitely worth the time to `man thing` and give it a skim.
If you're learning something new, it's definitely worth the time to `man thing` and give it a skim.
I haven't read this myself but you can download it for free.
https://opensource.com/downloads/pragmatic-guide-systemd-lin...
https://opensource.com/downloads/pragmatic-guide-systemd-lin...
What is it exactly that is being deprecated here? systemd-sysv-generator? If the unit generator interface is stable, what's to stop downstream distributions from keeping using it regardless?
That's my read/thought too. The generator is lost, and distributions will probably be carrying an analogue forward -- for benefit of third party relics.
I don't believe it makes much more assumption than... $script {start,stop,restart} as the Exec lines in the unit
The hairy part is how package scriptlets and so on that assume SysV/want old utilities -- eg: chkconfig, service.
systemd captured these, and that may go away too
I don't believe it makes much more assumption than... $script {start,stop,restart} as the Exec lines in the unit
The hairy part is how package scriptlets and so on that assume SysV/want old utilities -- eg: chkconfig, service.
systemd captured these, and that may go away too
I think it’s being able to have stuff in /etc/init.d that show up as services in SystemD.
Oh goodie, another way for shit to break and force maintainers to write systemd only service scripts.
Good riddance! Sysvinit shell scripts are a pain to read and maintain. Developers that perpetuate systemd flamewars have gone from mildly entertaining memes to being a serious red flag and not anyone I’d ever want to work with. systemd and its ecosystem is proven and always getting better.
Don't you think it does a bit too much as an init system?
It’s not just an init system and you can opt into resolved, networkd, etc. but you knew that already!
Just being able to treat period tasks the same as I treat long-lived services, and never having to think about crontab vs cron.d vs cron.hourly vs /etc/crontab, has improved my quality of life dramatically.
I also use systemd-timesyncd / networkd / resolved on most of my systems, but in places where I've wanted to not, swapping them out is as easy as swapping any other services (looking at you, rsyslog and syslog-ng).
I also use systemd-timesyncd / networkd / resolved on most of my systems, but in places where I've wanted to not, swapping them out is as easy as swapping any other services (looking at you, rsyslog and syslog-ng).
No, it does what I want well. It never surprised me.
What does it do as an init system that is too much?
Not really, no. Systemd-init seems fairly focused. systemd the project also makes other stuff, which all neatly fits together.
No. It’s great, replacing and unifying a whole collection of random tooling you otherwise had to cobble together yourself.
Certainly! It can also be difficult to distinguish between being genuinely liked and politely tolerated because of being "good to have around".
I mean init systems, of course.
I mean init systems, of course.
jmclnx(2)
You do realise that sysvinit scripts are much, much, much more fragile?
Systemd has its share of problems but it's vastly better than a bag of spaghetti shell scripts.
Systemd has its share of problems but it's vastly better than a bag of spaghetti shell scripts.
The bag of spaghetti in systemd's case is not visible to you, but it's there in thousands and thousands of C code (and I use systemd).
Yes, systemd is far from trivial. The model of its operation is rather convoluted.
But most people just don't care. long running applications are wrapped in a control group, can be reliably killed, stopped, etc.
There some questions around binary logs, yes, but nothing truly unbearable.
But most people just don't care. long running applications are wrapped in a control group, can be reliably killed, stopped, etc.
There some questions around binary logs, yes, but nothing truly unbearable.
Which is the proper place for complexity to live in and get properly tested by millions of boots each minute. Remember, essential complexity of a task can never be reduced.
As opposed to that shitty bash script you pasted from 3 stackoverflow answers that already has 3 bugs just from existing, let alone all the indeterminacy that comes with it execution with all the other similarly shitty bash scripts, all unique to your system.
As opposed to that shitty bash script you pasted from 3 stackoverflow answers that already has 3 bugs just from existing, let alone all the indeterminacy that comes with it execution with all the other similarly shitty bash scripts, all unique to your system.
"will be removed in a future release"
So this is not even planned to be removed for some releases. TBH I'm surprised it wasn't already deprecated.
So this is not even planned to be removed for some releases. TBH I'm surprised it wasn't already deprecated.
Yea, woe is me - having to be aware of an init system. If you want users, you'll cater to them. Distribution maintainers do.
Here's the Unit, what this provides:
... one could skip the init script, offloading whatever nonsense it does to the DSL of systemd.
It takes hardly any effort, searching for obvious keywords with 'man systemd.{unit,service,exec}' at your disposal. A likely one is 'Environment' for, well, environment variables.
Save yourself dozens of lines of code and support it. It's noble to work without, but why deliberately limit yourself beyond making an unheard statement?
It's not removed yet, there's time.
Here's the Unit, what this provides:
[Unit]
Description=Whatever
After=network.target network-online.target
[Service]
Type=forking
ExecStart=/etc/init.d/your_awesome_initscript start
ExecStop=/etc/init.d/your_awesome_initscript stop
ExecReload=/etc/init.d/your_awesome_initscript restart
[Install]
WantedBy=some.target
... one could skip the init script, offloading whatever nonsense it does to the DSL of systemd.
It takes hardly any effort, searching for obvious keywords with 'man systemd.{unit,service,exec}' at your disposal. A likely one is 'Environment' for, well, environment variables.
Save yourself dozens of lines of code and support it. It's noble to work without, but why deliberately limit yourself beyond making an unheard statement?
It's not removed yet, there's time.
As someone else has pointed out, this is only a deprecation at this point.
For comparison, support for `cgroups v1` which is being removed in this release, was described as "legacy", and to be removed in a later version, happened with systemd v233 released in March 2017. That's more than 6 years between deprecation and removal.
Also, `cgroups v1` systems were marked as "tainted" starting in v248 released in March 2021.
Based on that, you've probably got a few years yet before your sysv scripts actually start breaking, and you'll probably get a more visible heads-up a couple of years before it actually happens.
For comparison, support for `cgroups v1` which is being removed in this release, was described as "legacy", and to be removed in a later version, happened with systemd v233 released in March 2017. That's more than 6 years between deprecation and removal.
Also, `cgroups v1` systems were marked as "tainted" starting in v248 released in March 2021.
Based on that, you've probably got a few years yet before your sysv scripts actually start breaking, and you'll probably get a more visible heads-up a couple of years before it actually happens.
Embrace, Extend, Extinguish.
There was no embrace step; systemd served to replace sysvinit with a new way of doing things, supporting sysvinit scripts for backwards compatibility only.
There was no extend; systemd's sysvinit scripts didn't have features which are lacking from the original sysvinit in an effort to cause the proliferation of sysvinit scripts which only work with systemd.
EEE is a very specific strategy. It's not the general concept of making a new system to replace an old system.
There was no extend; systemd's sysvinit scripts didn't have features which are lacking from the original sysvinit in an effort to cause the proliferation of sysvinit scripts which only work with systemd.
EEE is a very specific strategy. It's not the general concept of making a new system to replace an old system.
But it never actually did support sysv init scripts, because it fundamentally can't. All it has is ExecStart which is trivial garbage that does not replicate or emulate sysvinit functionality at all.
I had a tiny little simple 2k init script that managed lxc containers.
It provided: * graceful start all at boot * graceful wait while shutdown all at shutdown * Enable/disable of individual containers * Start/stop of individual containers * Console access to individual containers * Query status (running/not/etc) of individual containers at any time. * Query status of entire metaservice at any time
All without any manager/monitor daemon either for the metaservice or the individual containers, and the script was tiny, maybe not even 2k.
Under systemd, it's not possible to have an init script that can just check the status and then exit again, and where the definition of status is whatever conditions you want to code up. There is no ExecStatus because the fundamental way systemd tracks upness or downness is not by performing an action to get the answer but by monitoring a process or a port or a file itself.
It requires a constantly running daemon of some sort that systemd can detect that it exited or is still running, or it requires one of a few other things that systemd just declares as all the possible options anyone can ever need. A port, a file, a process etc.
The way my script answered the up or down question was it examined a few things about the container and decided based on what it saw. There didn't need to be any persistent process dedicated to monitoring a container, or all containers. The containers could run any sort of processes and didn't have to do anything a certain way in order to coordinate. IE, a container might have it's own copy of init as it's pid 1, or just bash, or screen, or a random binary. The script got it's info from kernel cgroups info by reading files and making a determination based on the contents of the files. It did this on demand and only when requested. There was no server process to monitor, no pid/lock file to monitor, no port to monitor.
I'm not saying the cost of another process is so intolerable, I'm saying you can't actually do whatever you might want to do. You can only do that which the lord hath provided for.
In a sysv script, you are free to code up whatever unpredictable logic you may happen to need, without the init author from 50 years ago having to predict what your needs will be and providing some managed limited answer for those specific predicted needs.
Init not only doesn't care what you write in your script, it doesn't even care if it's a script at all. It doesn't have to be sh or even any scripting language, it could be a binary.
The joy and relief of systemd is the relief of "everything would be so much simpler if everyone just did exactly the same thing", which is the same as saying if everyone else just did what I say.
Here's how you know systemd's claim to being a good citizen is bs: Why can't I run systemd as just another service that isn't pid 1?
I would have had far less problem with systemd merely existing in the world if it were like say xinetd where it could be run as a service that managed other services that wanted it, but was not pid 1 because I happen to want init, or any other thing of my choice to be pid 1, for whatever my reasons are, and systemd nor Poettering nor anyone else has any right to know or care what those reasons are, certainly not to decide for me that they are not valid.
systemd presumes to know all the possible valid ways any service could operate, and any service that isn't covered is conveniently by definition invalid or insane, and so doesn't matter. Systemd is tight coupling. In every other aspect of IT, tight coupling is recognized as inflexible bad architecture.
And this is all just the process/service management parts. The binary logs are a whole other example of tight coupling. It's a pattern.
I had a tiny little simple 2k init script that managed lxc containers.
It provided: * graceful start all at boot * graceful wait while shutdown all at shutdown * Enable/disable of individual containers * Start/stop of individual containers * Console access to individual containers * Query status (running/not/etc) of individual containers at any time. * Query status of entire metaservice at any time
All without any manager/monitor daemon either for the metaservice or the individual containers, and the script was tiny, maybe not even 2k.
Under systemd, it's not possible to have an init script that can just check the status and then exit again, and where the definition of status is whatever conditions you want to code up. There is no ExecStatus because the fundamental way systemd tracks upness or downness is not by performing an action to get the answer but by monitoring a process or a port or a file itself.
It requires a constantly running daemon of some sort that systemd can detect that it exited or is still running, or it requires one of a few other things that systemd just declares as all the possible options anyone can ever need. A port, a file, a process etc.
The way my script answered the up or down question was it examined a few things about the container and decided based on what it saw. There didn't need to be any persistent process dedicated to monitoring a container, or all containers. The containers could run any sort of processes and didn't have to do anything a certain way in order to coordinate. IE, a container might have it's own copy of init as it's pid 1, or just bash, or screen, or a random binary. The script got it's info from kernel cgroups info by reading files and making a determination based on the contents of the files. It did this on demand and only when requested. There was no server process to monitor, no pid/lock file to monitor, no port to monitor.
I'm not saying the cost of another process is so intolerable, I'm saying you can't actually do whatever you might want to do. You can only do that which the lord hath provided for.
In a sysv script, you are free to code up whatever unpredictable logic you may happen to need, without the init author from 50 years ago having to predict what your needs will be and providing some managed limited answer for those specific predicted needs.
Init not only doesn't care what you write in your script, it doesn't even care if it's a script at all. It doesn't have to be sh or even any scripting language, it could be a binary.
The joy and relief of systemd is the relief of "everything would be so much simpler if everyone just did exactly the same thing", which is the same as saying if everyone else just did what I say.
Here's how you know systemd's claim to being a good citizen is bs: Why can't I run systemd as just another service that isn't pid 1?
I would have had far less problem with systemd merely existing in the world if it were like say xinetd where it could be run as a service that managed other services that wanted it, but was not pid 1 because I happen to want init, or any other thing of my choice to be pid 1, for whatever my reasons are, and systemd nor Poettering nor anyone else has any right to know or care what those reasons are, certainly not to decide for me that they are not valid.
systemd presumes to know all the possible valid ways any service could operate, and any service that isn't covered is conveniently by definition invalid or insane, and so doesn't matter. Systemd is tight coupling. In every other aspect of IT, tight coupling is recognized as inflexible bad architecture.
And this is all just the process/service management parts. The binary logs are a whole other example of tight coupling. It's a pattern.
Maybe read the manpages, instead of ranting.
Maybe you should?
I took the time to describe an actual problem, you didn't even so much as link to the supposed page that you imply negates it.
Regardless, no man page "informs away" the tight coupling.
How can you even remove support for something if you aen't coupled enough that it's even possible become no longer compatible?
The very fact that the announcement "we're deprecating init scripts" even makes any sense proves the point all by itself.
I took the time to describe an actual problem, you didn't even so much as link to the supposed page that you imply negates it.
Regardless, no man page "informs away" the tight coupling.
How can you even remove support for something if you aen't coupled enough that it's even possible become no longer compatible?
The very fact that the announcement "we're deprecating init scripts" even makes any sense proves the point all by itself.
This is a low effort post. Please don’t do that here. What about these words compelled you to post them? Tell us what’s in your brain!
told you.
Just like pulsed, he won't stop until every existing, non-default config breaks. Just like pipewire, he will start a "better" alternative and restart the stuff breaking cycle
Just like pulsed, he won't stop until every existing, non-default config breaks. Just like pipewire, he will start a "better" alternative and restart the stuff breaking cycle
systemd's been the default init for every major distro since 2015[0], and has existed as a project since roughly 2010. I think ten years of support for the predecessor is probably good enough. This is just a warning anyway.
Lennart also didn't start Pipewire (which as far as I know, has been happily accepted by almost everyone?) and while I was just as annoyed at PulseAudio breaking my sound setup back in 2008 I think these days it's a bit remiss to keep bringing that up as an argument. At least not without talking about how a lot of the issues with it was due to Pulse revealing bugs in the sound card drivers.
[0] Going by https://en.wikipedia.org/wiki/Systemd#Adoption and yes I'm only counting Arch,Debian,Ubuntu,Fedora,SUSE,and RHEL as the major distros. I could see an argument for Mint or Gentoo in there, but most of that table is honestly pretty useless (I still have my Knoppix floppies as coasters, but I really don't care about whether they've adopted systemd at this point)
EDIT: mild edit, sorry it was Wolvix I have as floppies. Knoppix was only on CDs and I'm not sure where mine went.
Lennart also didn't start Pipewire (which as far as I know, has been happily accepted by almost everyone?) and while I was just as annoyed at PulseAudio breaking my sound setup back in 2008 I think these days it's a bit remiss to keep bringing that up as an argument. At least not without talking about how a lot of the issues with it was due to Pulse revealing bugs in the sound card drivers.
[0] Going by https://en.wikipedia.org/wiki/Systemd#Adoption and yes I'm only counting Arch,Debian,Ubuntu,Fedora,SUSE,and RHEL as the major distros. I could see an argument for Mint or Gentoo in there, but most of that table is honestly pretty useless (I still have my Knoppix floppies as coasters, but I really don't care about whether they've adopted systemd at this point)
EDIT: mild edit, sorry it was Wolvix I have as floppies. Knoppix was only on CDs and I'm not sure where mine went.
pipewire was not started by Lennart Poettering
and also it really is better— and quite stable already!
pengaru(1)
```
[Unit]
Description=my app
[Service]
Restart=on-failure
User=webservices
Group=webservices
ExecStart=/usr/local/bin/my-web-service
[Install]
WantedBy=multi-user.target
```
It couldn't really be any simpler.
There's also https://github.com/gdraheim/docker-systemctl-replacement# for anyone who needs a "lighter" alternative for tests in Docker.