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.
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.
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.
Unit files are far more functional for the same amount of effort as SysV scripts.
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.
Besides Nix, it’s the easiest way I’ve found to declaratively define a system that just works.
```
[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.
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.
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.
It's the simple things that reduce friction that matter. Devs never understand this.
"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.
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.
just...wow.
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.
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...
I mean init systems, of course.
Systemd has its share of problems but it's vastly better than a bag of spaghetti shell scripts.
So this is not even planned to be removed for some releases. TBH I'm surprised it wasn't already deprecated.
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.
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.
(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.)
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.)
Took some decades to collectively get tired enough to decide on a language to declare it
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.
> 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
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
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.
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.
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?
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.
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.
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
- 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.
Yes, I know why. IBMHat makes me like FreeBSD more with every power grab.
Systems is also are deprecating non merged-/usr.
https://opensource.com/downloads/pragmatic-guide-systemd-lin...
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.
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.
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
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.
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
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.