4 ms·

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

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.

TacticalCoder 3y ago
> 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.
- bananapub 3y ago
  > 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?
- pengaru 3y ago
  > 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.
ninjin 3y ago
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 Never expected to be in a situation where I could not shut down a machine cleanly like that. But maybe I was missing something?
- freedomben 3y ago
  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
traverseda 3y ago
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.
nikau 3y ago
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.

TacticalCoder 3y ago

> 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.

bananapub 3y ago
> 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?
pengaru 3y ago
> 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.

ninjin 3y ago

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 Never expected to be in a situation where I could not shut down a machine cleanly like that. But maybe I was missing something?

freedomben 3y ago
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

traverseda 3y ago

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.

nikau 3y ago

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.