4 ms·

Ohh... I have sooooo many issues with systemd. The core systemd is fine, and the ideas behind it are sound. But it lacks any consistency. It's not a cohesive p

by cyberax 9mo ago

Ohh... I have sooooo many issues with systemd. The core systemd is fine, and the ideas behind it are sound. But it lacks any consistency. It's not a cohesive project with a vision, it's a collection of tools without any overarching idea. This is reflected in its documentation, it's an OK reference manual, but go on and try to build a full picture of system startup. To give you concrete examples: 1. Systemd has mount units, that you would expect to behave like regular units but for mounts. Except that they don't. You can specify the service retry/restart policy for regular units, including start/stop timeouts, but not for mounts. 2. Except that you can, but only if you use the /etc/fstab compat. 3. Except that you can not, if systemd thinks that your mounts are "local". How does it determine if mounts are local? By checking its mount device. 4. Systemd has separate behaviors for network and local filesystems. 5. One fun example of above, there's a unit that fires up after each system update. It inserts itself _before_ the network startup. Except that in my case, the /dev/sda is actually an iSCSI device and so it's remote. So systemd deadlocks, but only after a system update. FUN!!! 6. How does systemd recognize network filesystems? Why, it has a pre-configured list of them: https://github.com/systemd/systemd/blob/4c6afaab193fcdcb1f5adfe29cd9e0d27e67c55c/src/basic/mountpoint-util.c#L235 https://github.com/systemd/systemd/blob/4c6afaab193fcdcb1f5a... Yes, you read it correctly. A low-level mount code has special case for sshfs, that it detects by string-matching. 7. But you can override it, right? Nope. This list is complete and authoritative. Nobody would ever need fuse.s3fs . And if you do, see figure 1. I can go on for a looooong time.

nomel 9mo ago
5 and 6 sounds like good candidates for a bug reports/PR, if there's not already some "right" way to do it.
- cyberax 9mo ago
  They're already reported. And ignored. Have you _seen_ the systemd issue backlog? The iSCSI loop issue: https://github.com/systemd/systemd/issues/34164 https://github.com/systemd/systemd/issues/34164 It keeps popping up again and again and is summarily ignored. The remote FS detection also came up multiple times, and the maintainers don't care.
  - nomel 9mo ago
    > and the maintainers don't care. I'm not sure that's fair. I think better proof of this would be a rejected PR rather than a neglected bug report. This is Linux, after all. Problems found with specific hardware are almost always solved by people with that hardware, not the maintainers, who are usually busy with the 99%.
    - cyberax 9mo ago
      The problem here is more fundamental. Lennart refused to make all the /etc/fstab options available in regular mount units. And yes, there was an issue, no I'm too tired to look for it. The wording was pretty much: "Give up, and gtfo, this is not going to happen. Just because." I'm convinced that systemd can't be fixed by its current team of maintainers. They are just... untidy. I don't know about you, but if I end up writing low-level code that _needs_ to know whether the mounted file system is "remote", I won't do that by comparing against a hard-coded list of filesystems inside PID0. Or by using wild heuristics ("if it's on a block device, then it's local"). I would put these heuristics in a helper tool that populates the default values for mount units. Then allow users to override them as needed. With a separate inspector tool to flag possible loops.
      - dTal 9mo ago
        This is one example of a more general complaint about systemd and related projects: they force policy, rather than simply providing mechanisms. I recently did a deep dive on my laptop because I was curious about an oddity - the /sys file to change my screen backlight (aside, why /sys and not /dev anyway?) was writable only by root - yet any desktop shell running as my user had no problem reacting to brightness hotkeys. I wondered, how did this privilege escalation work? Where was the policy, and what property of my user account granted it the right to do this? It turns out the answer is that the desktop shells are firing off a dbus request to org.freedesktop.login1, which is caught by systemd-logind - or elogind in my case, since I do not care for systemd. A login manager seemed an odd place for screen brightness privilege escalation, but hey if it works whatever - it seemed like logind functioned as a sort of miscellaneous grab bag of vaguely console-related stuff. Generally speaking, it consults polkit rules to determine whether a user is allowed to do a thing. Not screen brightness, though. No polkit rules. Nothing in pkaction. logind was unilaterally consenting to change the brightness on my behalf. And on what grounds? It wasn't documented anywhere so I had to check the source code, where I found a slew of hardcoded criteria that mostly revolve around physical presence at the machine. Want to change screen brightness over ssh? Oh but why would you ever want to do that? Hope you have root access, you weirdo. I removed elogind. A few odds and ends broke. But nobody tells me what to do with my machine.
well_ackshually 9mo ago
[dead]
SuperNinKenDo 9mo ago
I love systemd, but you've hit on one of my biggest complaints. The mounting promises a cohesive system and instead gives you a completely broken mess, with mounts being split across .mount unit files, fstab, and worst of all, .service unit files. It's a totally incoherent mess, and that's only _after_ you figure out why nothing is working right, and build a complex mental model of every single feature that does or doesn't work in which scenario. Knowledge you only gain after screaming and tearing your hair out for a weekend. Your reward? A totally incoherent, inconsistend mess. I hate mounts in systemd.
- cyberax 9mo ago
  And don't forget automounts! They are so much fun!
jcarrano 9mo ago
That is one of my problems with systemd: it has way to much "magic" built in. SysVinit/OpenRC and related are easy to understand and debug: they only do what's in the scripts.

by cyberax 9mo ago

nomel 9mo ago

5 and 6 sounds like good candidates for a bug reports/PR, if there's not already some "right" way to do it.

cyberax 9mo ago
They're already reported. And ignored. Have you _seen_ the systemd issue backlog? The iSCSI loop issue: https://github.com/systemd/systemd/issues/34164 https://github.com/systemd/systemd/issues/34164 It keeps popping up again and again and is summarily ignored. The remote FS detection also came up multiple times, and the maintainers don't care.
- nomel 9mo ago
  > and the maintainers don't care. I'm not sure that's fair. I think better proof of this would be a rejected PR rather than a neglected bug report. This is Linux, after all. Problems found with specific hardware are almost always solved by people with that hardware, not the maintainers, who are usually busy with the 99%.
  - cyberax 9mo ago
    The problem here is more fundamental. Lennart refused to make all the /etc/fstab options available in regular mount units. And yes, there was an issue, no I'm too tired to look for it. The wording was pretty much: "Give up, and gtfo, this is not going to happen. Just because." I'm convinced that systemd can't be fixed by its current team of maintainers. They are just... untidy. I don't know about you, but if I end up writing low-level code that _needs_ to know whether the mounted file system is "remote", I won't do that by comparing against a hard-coded list of filesystems inside PID0. Or by using wild heuristics ("if it's on a block device, then it's local"). I would put these heuristics in a helper tool that populates the default values for mount units. Then allow users to override them as needed. With a separate inspector tool to flag possible loops.
    - dTal 9mo ago
      This is one example of a more general complaint about systemd and related projects: they force policy, rather than simply providing mechanisms. I recently did a deep dive on my laptop because I was curious about an oddity - the /sys file to change my screen backlight (aside, why /sys and not /dev anyway?) was writable only by root - yet any desktop shell running as my user had no problem reacting to brightness hotkeys. I wondered, how did this privilege escalation work? Where was the policy, and what property of my user account granted it the right to do this? It turns out the answer is that the desktop shells are firing off a dbus request to org.freedesktop.login1, which is caught by systemd-logind - or elogind in my case, since I do not care for systemd. A login manager seemed an odd place for screen brightness privilege escalation, but hey if it works whatever - it seemed like logind functioned as a sort of miscellaneous grab bag of vaguely console-related stuff. Generally speaking, it consults polkit rules to determine whether a user is allowed to do a thing. Not screen brightness, though. No polkit rules. Nothing in pkaction. logind was unilaterally consenting to change the brightness on my behalf. And on what grounds? It wasn't documented anywhere so I had to check the source code, where I found a slew of hardcoded criteria that mostly revolve around physical presence at the machine. Want to change screen brightness over ssh? Oh but why would you ever want to do that? Hope you have root access, you weirdo. I removed elogind. A few odds and ends broke. But nobody tells me what to do with my machine.

well_ackshually 9mo ago

[dead]

SuperNinKenDo 9mo ago

I love systemd, but you've hit on one of my biggest complaints. The mounting promises a cohesive system and instead gives you a completely broken mess, with mounts being split across .mount unit files, fstab, and worst of all, .service unit files. It's a totally incoherent mess, and that's only _after_ you figure out why nothing is working right, and build a complex mental model of every single feature that does or doesn't work in which scenario. Knowledge you only gain after screaming and tearing your hair out for a weekend. Your reward? A totally incoherent, inconsistend mess. I hate mounts in systemd.

cyberax 9mo ago
And don't forget automounts! They are so much fun!

jcarrano 9mo ago

That is one of my problems with systemd: it has way to much "magic" built in. SysVinit/OpenRC and related are easy to understand and debug: they only do what's in the scripts.