5 ms·

This is getting OT, but could you elaborate on your issues with systemd? I’m genuinely curious. I often see people complain but haven’t seen or experienced spec

This is getting OT, but could you elaborate on your issues with systemd? I’m genuinely curious. I often see people complain but haven’t seen or experienced specifics apart from it being complex and having higher learning curve than initd. (I don’t know if you’ve tried MX Linux BTW; Debian derivative without systemd by default) I will never defend pulseaudio though, that’s a horrible mess.

z3t4 6y ago
Systemd gives you less control. I used to pipe stderr to email, cant do that with sustemd. The journaling system is very slow compared to plain text files. Systemd overwrite mounts made by ip netns. Network settings is complicated with systemd. Not all bad though, setting up services is easy, and it has never failed to start a service for me so far, and it do start services in the correct order, which is all it should do imho.
- Legogris 6y ago
  Can't you just wrap your service? Something along the lines of > ExecStart=/bin/sh -c "/usr/bin/foo > /var/foo/bar 2>&1" As for networking, it's not like you have to buy in to systemd-networkd, systemd-resolved et al - or am I missing something? What I've definitely had issues with is the way networking services are configured in recent releases of Debian, but that's mostly from several of the network subsystems being in different degrees of weird limbo with "the new way" and "the old" interfering with each other. For example how resolv.conf is managed. And the whole back-and-forth with network names. Come to think of it, it's a bit reminiscent of snap/deb in Ubuntu 20.04 ;)
MereInterest 6y ago
My first experience with systemd was when they implemented a default that would kill processes when a user logs off. This may be acceptable in some single-user desktop environments, but it is absolutely unacceptable in any server environment. If I am using tmux, emacs --daemon, nohup, or any other custom program that catches SIGHUP, then it is inexcusable for systemd to escalate to sending SIGKILL. I know that there is a separate command that can be used to tell systemd to allow a program to live. I know that there are systemd libraries that an executable can link against in order to opt out of the new behavior. These do not matter, because they shows that systemd is willing to break existing programs, and to break specified conventions. Systemd developers cannot be trusted to provide a foundation to build upon. I know that this default setting can be overridden at the distribution level, or at the system level. This doesn't matter, because it shows that systemd developers do not know how to choose appropriate defaults, and that any changes that are made in systemd need to be continually monitored for stupidity. Maybe this is just me being soured by a very poor first impression of systemd, but I haven't seen anything since to dissuade me from this impression.
- macintux 6y ago
  > ... they implemented a default that would kill processes when a user logs off Is that still the default? That’s horrific.
  - thejsa 6y ago
    It doesn’t seem to do that on my Ubuntu 18.04 / 20.04 servers; I haven’t tried on desktop though as I don’t use Ubuntu there, would indeed be a huge violation of my expectations of how a system should work if so.
    - MereInterest 6y ago
      Most distributions have taken the sane route and changed this option at the distribution level. The point is more that any decisions systemd makes may be absolutely nuts, and need to be audited in detail by anybody choosing to use systemd. It is extra work that should never have been necessary, because systemd is untrustworthy.
  - MereInterest 6y ago
    As of this thread [1] in January 2019, yes. The user poettering is Lennart Poettering, the original Creator and lead developer of systemd, and doesn't show any signs of coming to the light. At this point, my standard .bashrc includes a check of whether systemd is running, and whether this absurd setting is set, so at least I will get some warning, and can either fix it or complain to the sysadmin. [1] https://news.ycombinator.com/item?id=19023232 https://news.ycombinator.com/item?id=19023232
lmm 6y ago
I've had systems become unbootable, services not start, that sort of thing. All perfectly understandable bugs that have been fixed, I'm sure, but fundamentally my experience is that it's this intrusive thing that I never asked for that's broken a bunch of stuff that was working fine before.
XelNika 6y ago
I like the init system (admittedly, I have not been using Linux long enough to remember a time before systemd), but components like networkd and resolved are a pain to work with in general. I've had the networkd DHCP client fail in situations that dhcpcd and dhclient handled with grace. It is not clear to me what benefit said systemd components provide over the more traditional solutions.

z3t4 6y ago

Systemd gives you less control. I used to pipe stderr to email, cant do that with sustemd. The journaling system is very slow compared to plain text files. Systemd overwrite mounts made by ip netns. Network settings is complicated with systemd. Not all bad though, setting up services is easy, and it has never failed to start a service for me so far, and it do start services in the correct order, which is all it should do imho.

Legogris 6y ago
Can't you just wrap your service? Something along the lines of > ExecStart=/bin/sh -c "/usr/bin/foo > /var/foo/bar 2>&1" As for networking, it's not like you have to buy in to systemd-networkd, systemd-resolved et al - or am I missing something? What I've definitely had issues with is the way networking services are configured in recent releases of Debian, but that's mostly from several of the network subsystems being in different degrees of weird limbo with "the new way" and "the old" interfering with each other. For example how resolv.conf is managed. And the whole back-and-forth with network names. Come to think of it, it's a bit reminiscent of snap/deb in Ubuntu 20.04 ;)

MereInterest 6y ago

My first experience with systemd was when they implemented a default that would kill processes when a user logs off. This may be acceptable in some single-user desktop environments, but it is absolutely unacceptable in any server environment. If I am using tmux, emacs --daemon, nohup, or any other custom program that catches SIGHUP, then it is inexcusable for systemd to escalate to sending SIGKILL. I know that there is a separate command that can be used to tell systemd to allow a program to live. I know that there are systemd libraries that an executable can link against in order to opt out of the new behavior. These do not matter, because they shows that systemd is willing to break existing programs, and to break specified conventions. Systemd developers cannot be trusted to provide a foundation to build upon. I know that this default setting can be overridden at the distribution level, or at the system level. This doesn't matter, because it shows that systemd developers do not know how to choose appropriate defaults, and that any changes that are made in systemd need to be continually monitored for stupidity. Maybe this is just me being soured by a very poor first impression of systemd, but I haven't seen anything since to dissuade me from this impression.

macintux 6y ago
> ... they implemented a default that would kill processes when a user logs off Is that still the default? That’s horrific.
- thejsa 6y ago
  It doesn’t seem to do that on my Ubuntu 18.04 / 20.04 servers; I haven’t tried on desktop though as I don’t use Ubuntu there, would indeed be a huge violation of my expectations of how a system should work if so.
  - MereInterest 6y ago
    Most distributions have taken the sane route and changed this option at the distribution level. The point is more that any decisions systemd makes may be absolutely nuts, and need to be audited in detail by anybody choosing to use systemd. It is extra work that should never have been necessary, because systemd is untrustworthy.
- MereInterest 6y ago
  As of this thread [1] in January 2019, yes. The user poettering is Lennart Poettering, the original Creator and lead developer of systemd, and doesn't show any signs of coming to the light. At this point, my standard .bashrc includes a check of whether systemd is running, and whether this absurd setting is set, so at least I will get some warning, and can either fix it or complain to the sysadmin. [1] https://news.ycombinator.com/item?id=19023232 https://news.ycombinator.com/item?id=19023232

lmm 6y ago

I've had systems become unbootable, services not start, that sort of thing. All perfectly understandable bugs that have been fixed, I'm sure, but fundamentally my experience is that it's this intrusive thing that I never asked for that's broken a bunch of stuff that was working fine before.

XelNika 6y ago

I like the init system (admittedly, I have not been using Linux long enough to remember a time before systemd), but components like networkd and resolved are a pain to work with in general. I've had the networkd DHCP client fail in situations that dhcpcd and dhclient handled with grace. It is not clear to me what benefit said systemd components provide over the more traditional solutions.