6 ms·

Systemd gets a lot of hate but it really solves a lot of problems. People really shouldn't dismiss it. I think it really happened because when systemd started a

Systemd gets a lot of hate but it really solves a lot of problems. People really shouldn't dismiss it. I think it really happened because when systemd started appearing on distros by default people were upset they had to change Here's some cool stuff: - containers - machinectl: used for controlling: - nspawn: a more powerful chroot. This is often a better solution than docker. Super lightweight. Shares kernel - vmspawn: when nspawn isn't enough and you need full virtualization - importctl: download, import, export your machines. Get the download features in {vm,n}spawn like we have with docker. There's a hub, but it's not very active - homed/homectl: extends user management to make it easier to do things like encryption home directories (different mounts), better control of permissions, and more - mounts: forget fstab. Make it easy to auto mount and dismount drives or partitions. Can be access based, time, triggered by another unit (eg a spawn), sockets, or whatever - boot: you can not only control boot but this is really what gives you access to starting and stopping services in the boot sequence. - timers: forget cron. Cron can't wake your machine. Cron can't tell a service didn't run because your machine was off. Cron won't give you fuzzy timing, do more complicated things like wait for X minutes after boot if it's the third Sunday of the month and only if Y.service is running. Idk why you'd do that, but you can! - service units: these are your jobs. You can really control them in their capabilities. Lock them down so they can only do what they are meant to do. - overrides: use `systemctl edit` to edit your configs. Creates an override config and you don't need to destroy the original. No longer that annoying task of finding the original config and for some reason you can't get it back even if reinstalling! Same with when the original config changes in an install, your override doesn't get touched!! It's got a lot of stuff and it's (almost) all there already on your system! It's a bit annoying to learn, but it really isn't too bad if you really don't want to do anything too complicated. But in that case, it's not like there's a tool that doesn't require docs but allows you to do super complicated things.

holuponemoment 2y ago
Nice list, I'd add run0 as the sudo replacement. My only bugbear with it is that there's no equivalent to the old timeout default you could set (note that doas explicitly said they won't implement this too). The workaround is to run it in `sudo -i` fashion and not put a command afterwards which is reasonable enough even though it worked hard against my muscle memory + copypaste commands when switching over. > Systemd gets a lot of hate I'd argue it doesn't and is simply another victim of loud internet minority syndrome. It's just a generic name at this point, basically all associated with init and service units and none of the other stuff. https://man.archlinux.org/man/run0.1.en https://man.archlinux.org/man/run0.1.en
- godelski 2y ago
  Oh yes, please add more! I'd love to see what others do because frankly, sometimes it feels like we're talking about forbidden magic or something lol And honestly, I think the one thing systemd is really missing is... people talking about it. That's realistically the best way to get more documentation and spread all the cool tricks that everyone finds. > I'd argue it doesn't I definitely agree on loud minority, but they're visible enough that anytime systemd is brought up you can't avoid them. But then again, lots of people have much more passion about their opinions than passion about understanding the thing they opine about.
- DonHopkins 2y ago
  I was dismayed at having to go from simple clean linear BSD 4.3 / SunOS 4.1.3 era /etc/rc /etc/rc.local init scripts to that tangled rat king abomination of symbolic links and rc.d sub-directories and run levels that is the SysV / Solaris Rube Goldberg device. So people who want to go back to the "good old days" of that AT&T claptrap sound insane to me. Even Slowlaris moved on to SMF.
- egorfine 2y ago
  > run0 as the sudo replacement Of course. We suffered with sudo for a couple of decades already! Obviously it's wrong and outdated and has to be replaced with whatever LP says is the new norm.
  - flexagoon 2y ago
    All of your comments mention something existing for a long time, but X11 and ALSA and IPv4 and many more technologies have been used by people for many decades, and yet they still suck and have a replacement available.
    - egorfine 2y ago
      X11 sucks today. It was so beautiful and incredibly useful back in the day. I'm not sure that ALSA sucks, though. cron and sudo definitely don't.
blueflow 2y ago
Then you have that machine that only runs an sshd and apache2 and you still get all that stuff shoehorned into your system.
- godelski 2y ago
  If you want that bare bones of a system I'd suggest using a minimal distribution. But honestly, I'm happy that I can wrap up servers and services into chroot jails with nspawn. Even when I'm not doing much, it makes it much easier to import, export, and limit capabilities Simple example is I can have a duplicate of the "machine" running my server and spin it up (or have it already spun up) and take over if something goes wrong. Makes for a much more seamless experience.
gwd 2y ago
> Systemd gets a lot of hate but it really solves a lot of problems. From my perspective, it got a lot of hate in its first few years (decade?), not because the project itself was bad -- on the contrary, it succeeded in spite of having loads of other issues, because it was so superior. The problem was the maintainer's attitude of wantonly breaking things that used to work just fine, without offering any suitable fixes. I have an old comment somewhere with a big list. If you never felt the pain of systemd, it's either because you came late to the party, or because your needs always happened to overlap with the core maintainer's needs.
- Aldipower 2y ago
  Full ack. Systemd broke a lot of things that just worked. Combined with the maintainer's attitude this produced a lot of anti reaction.
- gwd 2y ago
  Found my comment: https://news.ycombinator.com/item?id=21897993 https://news.ycombinator.com/item?id=21897993
  - godelski 2y ago
    Thanks for adding the perspective. I was much more of a casual user at the time so didn't see as much of this side. Just knew Arch always being Arch lol
  - Izkata 2y ago
    I got one missing from your list - systemd would kill screen and tmux sessions by design: https://superuser.com/questions/1372963/how-do-i-keep-systemd-from-killing-my-tmux-sessions https://superuser.com/questions/1372963/how-do-i-keep-system... From what I remember that's still the default in the project, but people stopped complaining because the individual distros started overriding the relevant settings.
- p_l 2y ago
  It didn't win on being superior [1] but because it was either systemd or you don't get to to use GNOME 3.8. On more than one distro it was the reason for switching towards systemd. I will fully admit though that upstart was worse (which is an achievement), but the solution space was not at all settled. [1] systemd project tackles a lot of important problems, but the quality of implementation, experience of using it, working with it, etc are not really good, especially the further you get from simplest cookie cutter services - especially because both systemd handling of defaults is borked, documentation when you hit that maybe makes sense to author, and whoever is the bright soul behind systemctl kindly never make CLIs again (with worst example being probably systemctl show this-service-does-not-exist)
rollcat 2y ago
The only issue I'm having with systemd is that it's taking over the role of PID 1, with a binary produced from an uncountable SLOC, then doing even more song and dance to exec itself in-place on upgrades. Here's a PID 1 program that does 100% of all of its duties correctly, and nothing else: #define _XOPEN_SOURCE 700 #include <signal.h> #include <unistd.h> int main() { sigset_t set; int status; if (getpid() != 1) return 1; sigfillset(&set); sigprocmask(SIG_BLOCK, &set, 0); if (fork()) for (;;) wait(&status); sigprocmask(SIG_UNBLOCK, &set, 0); setsid(); setpgid(0, 0); return execve("/etc/rc", (char *[]){ "rc", 0 }, (char *[]){ 0 }); } (Credit: https://ewontfix.com/14/ https://ewontfix.com/14/) You can spawn systemd from there, and in case anything goes wrong with it, you won't get an instant kernel panic.
- zoobab 2y ago
  "You can spawn systemd from there" Systemd wants PID1. Don't know if there are forks to disable that.
  - rollcat 2y ago
    And I want 192.168.1.1 as the IP of my workstation on corporate LAN. Both requirements are completely arbitrary. I guess if you really need that information, you could wait4 and dump pid/rusage to syslog. Nothing more to see here; these are zombies, orphans, by definition these processes have been disowned and there's nobody alive to tell the tale.
- ptsneves 2y ago
  If you have your init crashing wouldn't this just start a loop where you cannot do anything else than seeing it looping? How would this be better than just panicking?
  - rollcat 2y ago
    Don't restart it. Let it crash, but take note of the situation, whatever may help investigation, maybe send out a page, flush pending writes to disk, reboot gracefully, etc. Kernel panic should be the last resort, not the default.
dsp_person 2y ago
ooh i didn't know about vmspawn. maybe this can replace some of where I use incus
- godelski 2y ago
  It's a bit tricky and first and not a lot of good docs, but honestly I've been really liking it. I dropped docker in favor. Gives me a lot better control and flexibility.
  - dsp_person 2y ago
    Ah maybe a significant advantage of incus is it doesn't require sudo. I remember that also being required for nspawn.
    - godelski 2y ago
      Need to be booted by root, but not managed: https://wiki.archlinux.org/title/Systemd-nspawn#Unprivileged_containers https://wiki.archlinux.org/title/Systemd-nspawn#Unprivileged...
      - dsp_person 2y ago
        ah maybe there's a fully rootless option recently too https://github.com/systemd/systemd/issues/30239 https://github.com/systemd/systemd/issues/30239 https://github.com/systemd/systemd/pull/26826/files https://github.com/systemd/systemd/pull/26826/files systemd-nspawn may be invoked with or without privileges. The full functionality is currently only available when invoked with privileges. When invoked without privileges, various limitations apply, including, but not limited to
egorfine 2y ago
> forget cron Sure. It worked for _50 years_ just fine but obviously it is very wrong and should be replaced with - of course - systemd.
- MyOutfitIsVague 2y ago
  Timers are so much better than cron it's not even funny. Managing Unix machines for decades with teens of thousands of vital cron entries across thousands of machines, the things that can and do go wrong are painful, especially when you include more esoteric systems. The fact that timers are able to be synced up, backed up, and updated as individual files is alone a massive advantage. Some of these things that "worked for 50 years" have also actually sucked for 50 years. Look at C strings and C error handling. They've "worked", until you hold them slightly wrong and cause the entire world to start leaking sensitive data in a lesser-used code path.
  - egorfine 2y ago
    > have also actually sucked for 50 years I agree with you, that's exactly right. Not sure I'm on the same page with you on the cron. I have a similar experience but I'd rather say that cron was something that never gave me headaches. Unlike obviously systemd.
    - MyOutfitIsVague 2y ago
      Cron has given me a ton of headaches. Between skipped jobs on reboots and DST, inability to properly express some dates ("First Sunday of the Month" is a common one), and worst of all, complete inability to prevent the same job from running multiple times at once, it's been regular headaches for a shop who has leaned very heavily on it. Some cron daemons handle some of these things, but they're not standard, and AIX's cron daemon definitely doesn't have these features. Every job has to be wrapped in a bespoke script to manage things that systemd already does, but much worse. systemd has given me many headaches, but as a whole, it has saved me far fewer headaches than it has given me.
egorfine 2y ago
> homed/homectl: extends user management to make it impossible to have a clear picture of what's up with home dir, where is now located, how to have access to it or whether it will suddenly disappear. Obviously, plain /home worked for like five decades and therefore absolutely has to be replaced.
- jraph 2y ago
  > Obviously, plain /home worked for like five decades and therefore absolutely has to be replaced. Five decades ago, people didn't have laptops that they want to put on sleep and can get stolen. Actually, five decades ago, the rare people using a computer logged into remote, shared computers. Five decades ago, you didn't get hacked from the internet. Today, people mostly each have their computer, and one session for themselves in it (when they have a computer at all) I have not looked into homed yet, needs are very different from before. "It worked five decades ago" just isn't very convincing. It'd be better to understand what homed tries to address, and argue why it does it wrong or why the concerns are not right. You might not like it but there usually are legitimate reasons why systemd changes things, they don't do it because they like breaking stuff.
  - egorfine 2y ago
    It is. Laptops are totally unusable without systemd, and most of these features are needed there indeed. My rant is: why the f are they shoved down my throat on the server side then?
    - jraph 2y ago
      I'm quite happy with systemd on server side, it eases a lot of things there as well. And I haven't noticed homed on my servers. Did they shove homed down your throat on your servers?
      - egorfine 2y ago
        They did shove timers and mounts. So, homed and run0 are pending.
egorfine 2y ago
> mounts: forget fstab. Make it easy to never have your filesystem mounted at the right time, because their automount rules are convoluted and sometimes just plain don't work despite being 1:1 according to the documentation.
- bombela 2y ago
  Man this one annoys me. I have this server running a docker container with a specific application. And it writes to a specific filesystem (properly mount binded inside the container of course). Sometimes docker starts before the filesystem is mounted. I know systemd can be taught about this but I haven't bothered. Because every time I have to do something in systemd, I have to read some nasty obscure doc. I need know how and where the config should go. I did manage to disable journalctl at least. Because grepping through simple rotated log files is a billion times faster than journalctl. See my comment and the whole thread https://github.com/systemd/systemd/issues/2460#issuecomment-1577671723 https://github.com/systemd/systemd/issues/2460#issuecomment-... I like the concept of systemd. Not the implementation and its leader.
  - egorfine 2y ago
    > I did manage to disable journalctl at least My goodness. Absolutely fuck journald - a solution in search of a problem. I have created a bunch of different scripts to init my instances [1] on all projects. I do it differently from time to time, but one thing they all have in common is that journald gets removed and disabled. [1] https://github.com/egorFiNE/desystemd https://github.com/egorFiNE/desystemd
  - ptsneves 2y ago
    > I know systemd can be taught about this but I haven't bothered. I think After=<your .mount> will work. If you believe it can be taught (and it can) why do you blame your lack knowledge on the tool is not a strong argument against the quality of the tool. > Because grepping through simple rotated log files is a billion times faster than journalctl. `journalctl -D <directory of the journal files> | grep ...` will give you what you want. Systemd is incredibly configurable and that makes its documentation daunting but damn it does everything you want it to do. I used it in embedded systems and it is just amazing. In old times lots of custom programs and management daemons needed to be written. Now it is just a bunch of conf files and it all magically works. The most fair criticism is it does not follow the 'everything is a file philosophy' of Unix, and this makes discoverability and traditional workflows awkward. Even so it is a tool: if it does what you want, but you don't want to spend time understanding it, it is hardly the fault of the tool. I strongly recommend learning it, there will be many Ah-ha moments.
egorfine 2y ago
> boot: you can not only control boot but never boot into the network reliably, because under systemd you have no control over the sequence. BTW, I think that's one of the main pros and one of the strongest features of systemd, but it is also what makes it unreliable and boot unreproducible if you live outside of the very default Ubuntu instance and such.
- jraph 2y ago
  > never boot into the network reliably What does this mean? Your machine boots and sometimes doesn't have network? If your boot is unreliable, isn't it because some service you try to boot has a dependency that's not declared in its unit file?
  - egorfine 2y ago
    > Your machine boots and sometimes doesn't have network? Sometimes it waits on the network to be available with network being available. No idea what causes this. > some service you try to boot has a dependency that's not declared in its unit file Nah, that would be an obvious and easy fix.
    - jraph 2y ago
      Haven't noticed this. This looks like a bug more than a fundamental issue.
      - egorfine 2y ago
        My feeling is that this is not exactly a bug but rather an obscure side effect of systemd being non-transparent.
        ongy 2y ago
        The default hook systemd uses to wait for network is documented in https://www.freedesktop.org/software/systemd/man/latest/systemd-networkd-wait-online.service.html https://www.freedesktop.org/software/systemd/man/latest/syst... It has the slightly odd behavior with trying to get all configured links up. This can lead to some unexpected behavior when there's more than one. But yea, the upstream stance is essentially "don't rely on network to be up before you start. That's bad software. You have to deal with network going down and back up in practice either way." Which is often not super useful.
egorfine 2y ago
> It's a bit annoying to learn Learning curve is not the annoying part. It is kind of expected and fine. systemd is annoying is parts that are so well described over the internet, that it makes it zero sense to repeat it. I am just venting and that comes from the experience.
yc-kraln 2y ago
Systemd is great if your use case is Linux on a modern Desktop or Server, or something which resembles that. If you want to do anything else that doesn't fit into the project view of what you should be doing, you will be met with scorn and resistance (ask the musl team...). What isn't great, and where the hate comes from, is that it makes the life of a distribution or upstream super easy, at the expense of adding a (slowly growing) complexity at the lowest levels of your system that--depending your perspective--does not follow the "unix way": journalctl, timedatectl, dependencies on/replacing dbus, etc. etc. It's also somehow been conflated with Poettering (he can be grating in his correctness), as well as the other projects Poettering works on (Avahi, Pulse Audio). If all you want to do is coordinate some processes and ensure they run in the right order with automatic activation, etc. it's certainly capable and, I'd argue, the right level of tool as compared to something like k8s or docker.

holuponemoment 2y ago

Nice list, I'd add run0 as the sudo replacement. My only bugbear with it is that there's no equivalent to the old timeout default you could set (note that doas explicitly said they won't implement this too). The workaround is to run it in `sudo -i` fashion and not put a command afterwards which is reasonable enough even though it worked hard against my muscle memory + copypaste commands when switching over. > Systemd gets a lot of hate I'd argue it doesn't and is simply another victim of loud internet minority syndrome. It's just a generic name at this point, basically all associated with init and service units and none of the other stuff. https://man.archlinux.org/man/run0.1.en https://man.archlinux.org/man/run0.1.en

godelski 2y ago
Oh yes, please add more! I'd love to see what others do because frankly, sometimes it feels like we're talking about forbidden magic or something lol And honestly, I think the one thing systemd is really missing is... people talking about it. That's realistically the best way to get more documentation and spread all the cool tricks that everyone finds. > I'd argue it doesn't I definitely agree on loud minority, but they're visible enough that anytime systemd is brought up you can't avoid them. But then again, lots of people have much more passion about their opinions than passion about understanding the thing they opine about.
DonHopkins 2y ago
I was dismayed at having to go from simple clean linear BSD 4.3 / SunOS 4.1.3 era /etc/rc /etc/rc.local init scripts to that tangled rat king abomination of symbolic links and rc.d sub-directories and run levels that is the SysV / Solaris Rube Goldberg device. So people who want to go back to the "good old days" of that AT&T claptrap sound insane to me. Even Slowlaris moved on to SMF.
egorfine 2y ago
> run0 as the sudo replacement Of course. We suffered with sudo for a couple of decades already! Obviously it's wrong and outdated and has to be replaced with whatever LP says is the new norm.
- flexagoon 2y ago
  All of your comments mention something existing for a long time, but X11 and ALSA and IPv4 and many more technologies have been used by people for many decades, and yet they still suck and have a replacement available.
  - egorfine 2y ago
    X11 sucks today. It was so beautiful and incredibly useful back in the day. I'm not sure that ALSA sucks, though. cron and sudo definitely don't.

blueflow 2y ago

Then you have that machine that only runs an sshd and apache2 and you still get all that stuff shoehorned into your system.

godelski 2y ago
If you want that bare bones of a system I'd suggest using a minimal distribution. But honestly, I'm happy that I can wrap up servers and services into chroot jails with nspawn. Even when I'm not doing much, it makes it much easier to import, export, and limit capabilities Simple example is I can have a duplicate of the "machine" running my server and spin it up (or have it already spun up) and take over if something goes wrong. Makes for a much more seamless experience.

gwd 2y ago

> Systemd gets a lot of hate but it really solves a lot of problems. From my perspective, it got a lot of hate in its first few years (decade?), not because the project itself was bad -- on the contrary, it succeeded in spite of having loads of other issues, because it was so superior. The problem was the maintainer's attitude of wantonly breaking things that used to work just fine, without offering any suitable fixes. I have an old comment somewhere with a big list. If you never felt the pain of systemd, it's either because you came late to the party, or because your needs always happened to overlap with the core maintainer's needs.

Aldipower 2y ago
Full ack. Systemd broke a lot of things that just worked. Combined with the maintainer's attitude this produced a lot of anti reaction.
gwd 2y ago
Found my comment: https://news.ycombinator.com/item?id=21897993 https://news.ycombinator.com/item?id=21897993
- godelski 2y ago
  Thanks for adding the perspective. I was much more of a casual user at the time so didn't see as much of this side. Just knew Arch always being Arch lol
- Izkata 2y ago
  I got one missing from your list - systemd would kill screen and tmux sessions by design: https://superuser.com/questions/1372963/how-do-i-keep-systemd-from-killing-my-tmux-sessions https://superuser.com/questions/1372963/how-do-i-keep-system... From what I remember that's still the default in the project, but people stopped complaining because the individual distros started overriding the relevant settings.
p_l 2y ago
It didn't win on being superior [1] but because it was either systemd or you don't get to to use GNOME 3.8. On more than one distro it was the reason for switching towards systemd. I will fully admit though that upstart was worse (which is an achievement), but the solution space was not at all settled. [1] systemd project tackles a lot of important problems, but the quality of implementation, experience of using it, working with it, etc are not really good, especially the further you get from simplest cookie cutter services - especially because both systemd handling of defaults is borked, documentation when you hit that maybe makes sense to author, and whoever is the bright soul behind systemctl kindly never make CLIs again (with worst example being probably systemctl show this-service-does-not-exist)

rollcat 2y ago

The only issue I'm having with systemd is that it's taking over the role of PID 1, with a binary produced from an uncountable SLOC, then doing even more song and dance to exec itself in-place on upgrades. Here's a PID 1 program that does 100% of all of its duties correctly, and nothing else: #define _XOPEN_SOURCE 700 #include <signal.h> #include <unistd.h> int main() { sigset_t set; int status; if (getpid() != 1) return 1; sigfillset(&set); sigprocmask(SIG_BLOCK, &set, 0); if (fork()) for (;;) wait(&status); sigprocmask(SIG_UNBLOCK, &set, 0); setsid(); setpgid(0, 0); return execve("/etc/rc", (char *[]){ "rc", 0 }, (char *[]){ 0 }); } (Credit: https://ewontfix.com/14/ https://ewontfix.com/14/) You can spawn systemd from there, and in case anything goes wrong with it, you won't get an instant kernel panic.

zoobab 2y ago
"You can spawn systemd from there" Systemd wants PID1. Don't know if there are forks to disable that.
- rollcat 2y ago
  And I want 192.168.1.1 as the IP of my workstation on corporate LAN. Both requirements are completely arbitrary. I guess if you really need that information, you could wait4 and dump pid/rusage to syslog. Nothing more to see here; these are zombies, orphans, by definition these processes have been disowned and there's nobody alive to tell the tale.
ptsneves 2y ago
If you have your init crashing wouldn't this just start a loop where you cannot do anything else than seeing it looping? How would this be better than just panicking?
- rollcat 2y ago
  Don't restart it. Let it crash, but take note of the situation, whatever may help investigation, maybe send out a page, flush pending writes to disk, reboot gracefully, etc. Kernel panic should be the last resort, not the default.

dsp_person 2y ago

ooh i didn't know about vmspawn. maybe this can replace some of where I use incus

godelski 2y ago
It's a bit tricky and first and not a lot of good docs, but honestly I've been really liking it. I dropped docker in favor. Gives me a lot better control and flexibility.
- dsp_person 2y ago
  Ah maybe a significant advantage of incus is it doesn't require sudo. I remember that also being required for nspawn.
  - godelski 2y ago
    Need to be booted by root, but not managed: https://wiki.archlinux.org/title/Systemd-nspawn#Unprivileged_containers https://wiki.archlinux.org/title/Systemd-nspawn#Unprivileged...
    - dsp_person 2y ago
      ah maybe there's a fully rootless option recently too https://github.com/systemd/systemd/issues/30239 https://github.com/systemd/systemd/issues/30239 https://github.com/systemd/systemd/pull/26826/files https://github.com/systemd/systemd/pull/26826/files systemd-nspawn may be invoked with or without privileges. The full functionality is currently only available when invoked with privileges. When invoked without privileges, various limitations apply, including, but not limited to

egorfine 2y ago

> forget cron Sure. It worked for _50 years_ just fine but obviously it is very wrong and should be replaced with - of course - systemd.

MyOutfitIsVague 2y ago
Timers are so much better than cron it's not even funny. Managing Unix machines for decades with teens of thousands of vital cron entries across thousands of machines, the things that can and do go wrong are painful, especially when you include more esoteric systems. The fact that timers are able to be synced up, backed up, and updated as individual files is alone a massive advantage. Some of these things that "worked for 50 years" have also actually sucked for 50 years. Look at C strings and C error handling. They've "worked", until you hold them slightly wrong and cause the entire world to start leaking sensitive data in a lesser-used code path.
- egorfine 2y ago
  > have also actually sucked for 50 years I agree with you, that's exactly right. Not sure I'm on the same page with you on the cron. I have a similar experience but I'd rather say that cron was something that never gave me headaches. Unlike obviously systemd.
  - MyOutfitIsVague 2y ago
    Cron has given me a ton of headaches. Between skipped jobs on reboots and DST, inability to properly express some dates ("First Sunday of the Month" is a common one), and worst of all, complete inability to prevent the same job from running multiple times at once, it's been regular headaches for a shop who has leaned very heavily on it. Some cron daemons handle some of these things, but they're not standard, and AIX's cron daemon definitely doesn't have these features. Every job has to be wrapped in a bespoke script to manage things that systemd already does, but much worse. systemd has given me many headaches, but as a whole, it has saved me far fewer headaches than it has given me.

egorfine 2y ago

> homed/homectl: extends user management to make it impossible to have a clear picture of what's up with home dir, where is now located, how to have access to it or whether it will suddenly disappear. Obviously, plain /home worked for like five decades and therefore absolutely has to be replaced.

jraph 2y ago
> Obviously, plain /home worked for like five decades and therefore absolutely has to be replaced. Five decades ago, people didn't have laptops that they want to put on sleep and can get stolen. Actually, five decades ago, the rare people using a computer logged into remote, shared computers. Five decades ago, you didn't get hacked from the internet. Today, people mostly each have their computer, and one session for themselves in it (when they have a computer at all) I have not looked into homed yet, needs are very different from before. "It worked five decades ago" just isn't very convincing. It'd be better to understand what homed tries to address, and argue why it does it wrong or why the concerns are not right. You might not like it but there usually are legitimate reasons why systemd changes things, they don't do it because they like breaking stuff.
- egorfine 2y ago
  It is. Laptops are totally unusable without systemd, and most of these features are needed there indeed. My rant is: why the f are they shoved down my throat on the server side then?
  - jraph 2y ago
    I'm quite happy with systemd on server side, it eases a lot of things there as well. And I haven't noticed homed on my servers. Did they shove homed down your throat on your servers?
    - egorfine 2y ago
      They did shove timers and mounts. So, homed and run0 are pending.

egorfine 2y ago

> mounts: forget fstab. Make it easy to never have your filesystem mounted at the right time, because their automount rules are convoluted and sometimes just plain don't work despite being 1:1 according to the documentation.

bombela 2y ago
Man this one annoys me. I have this server running a docker container with a specific application. And it writes to a specific filesystem (properly mount binded inside the container of course). Sometimes docker starts before the filesystem is mounted. I know systemd can be taught about this but I haven't bothered. Because every time I have to do something in systemd, I have to read some nasty obscure doc. I need know how and where the config should go. I did manage to disable journalctl at least. Because grepping through simple rotated log files is a billion times faster than journalctl. See my comment and the whole thread https://github.com/systemd/systemd/issues/2460#issuecomment-1577671723 https://github.com/systemd/systemd/issues/2460#issuecomment-... I like the concept of systemd. Not the implementation and its leader.
- egorfine 2y ago
  > I did manage to disable journalctl at least My goodness. Absolutely fuck journald - a solution in search of a problem. I have created a bunch of different scripts to init my instances [1] on all projects. I do it differently from time to time, but one thing they all have in common is that journald gets removed and disabled. [1] https://github.com/egorFiNE/desystemd https://github.com/egorFiNE/desystemd
- ptsneves 2y ago
  > I know systemd can be taught about this but I haven't bothered. I think After=<your .mount> will work. If you believe it can be taught (and it can) why do you blame your lack knowledge on the tool is not a strong argument against the quality of the tool. > Because grepping through simple rotated log files is a billion times faster than journalctl. `journalctl -D <directory of the journal files> | grep ...` will give you what you want. Systemd is incredibly configurable and that makes its documentation daunting but damn it does everything you want it to do. I used it in embedded systems and it is just amazing. In old times lots of custom programs and management daemons needed to be written. Now it is just a bunch of conf files and it all magically works. The most fair criticism is it does not follow the 'everything is a file philosophy' of Unix, and this makes discoverability and traditional workflows awkward. Even so it is a tool: if it does what you want, but you don't want to spend time understanding it, it is hardly the fault of the tool. I strongly recommend learning it, there will be many Ah-ha moments.

egorfine 2y ago

> boot: you can not only control boot but never boot into the network reliably, because under systemd you have no control over the sequence. BTW, I think that's one of the main pros and one of the strongest features of systemd, but it is also what makes it unreliable and boot unreproducible if you live outside of the very default Ubuntu instance and such.

jraph 2y ago
> never boot into the network reliably What does this mean? Your machine boots and sometimes doesn't have network? If your boot is unreliable, isn't it because some service you try to boot has a dependency that's not declared in its unit file?
- egorfine 2y ago
  > Your machine boots and sometimes doesn't have network? Sometimes it waits on the network to be available with network being available. No idea what causes this. > some service you try to boot has a dependency that's not declared in its unit file Nah, that would be an obvious and easy fix.
  - jraph 2y ago
    Haven't noticed this. This looks like a bug more than a fundamental issue.
    - egorfine 2y ago
      My feeling is that this is not exactly a bug but rather an obscure side effect of systemd being non-transparent.
      - ongy 2y ago
        The default hook systemd uses to wait for network is documented in https://www.freedesktop.org/software/systemd/man/latest/systemd-networkd-wait-online.service.html https://www.freedesktop.org/software/systemd/man/latest/syst... It has the slightly odd behavior with trying to get all configured links up. This can lead to some unexpected behavior when there's more than one. But yea, the upstream stance is essentially "don't rely on network to be up before you start. That's bad software. You have to deal with network going down and back up in practice either way." Which is often not super useful.

egorfine 2y ago

> It's a bit annoying to learn Learning curve is not the annoying part. It is kind of expected and fine. systemd is annoying is parts that are so well described over the internet, that it makes it zero sense to repeat it. I am just venting and that comes from the experience.

yc-kraln 2y ago

Systemd is great if your use case is Linux on a modern Desktop or Server, or something which resembles that. If you want to do anything else that doesn't fit into the project view of what you should be doing, you will be met with scorn and resistance (ask the musl team...). What isn't great, and where the hate comes from, is that it makes the life of a distribution or upstream super easy, at the expense of adding a (slowly growing) complexity at the lowest levels of your system that--depending your perspective--does not follow the "unix way": journalctl, timedatectl, dependencies on/replacing dbus, etc. etc. It's also somehow been conflated with Poettering (he can be grating in his correctness), as well as the other projects Poettering works on (Avahi, Pulse Audio). If all you want to do is coordinate some processes and ensure they run in the right order with automatic activation, etc. it's certainly capable and, I'd argue, the right level of tool as compared to something like k8s or docker.