6 ms·

I always found systemd to be fine (I'm not a sysadmin, just prefer Linux on my PCs). PulseAudio did have some growing pains, though. I don't remember them exac

I always found systemd to be fine (I'm not a sysadmin, just prefer Linux on my PCs). PulseAudio did have some growing pains, though. I don't remember them exactly, but I remember having to tinker way too much to get apps to work together/correctly between ALSA and PulseAudio, etc. I still have a finicky laptop that REFUSES to do audio over HDMI unless I boot the machine with the HDMI cable plugged in already. No real point, here. Just rambling.

Shared404 6y ago
> I always found systemd to be fine (I'm not a sysadmin, just prefer Linux on my PCs). I mostly agree, although I prefer OpenRC personally. I was bit by [* ] Stopping service 1:30 remaining too many times to really like SystemD, although I tolerate it on my daily driver these days.
- alyandon 6y ago
  You can fix the problematic service with: systemctl edit service-name [Service] TimeoutStopSec=XX You can also override the global default DefaultTimeoutStopSec in /etc/systemd/system.conf.
  - unanswered 6y ago
    See, this right here is the (technical, not social) problem with systemd. Whether anyone points out that systemd is doing something stupid and wrong, the systemd shills' answer is always "well duh what did you expect when you didn't modify one of the hundred default configuration files to have `[stupidshit] = false`! You brought this on yourself!" And you're lucky if that even works to solve the problem.
    - jamespo 6y ago
      Yes bring back the handwritten shellscripts to start up & shut down services
    - deleted 6y ago
      [deleted]
    - zorked 6y ago
      What's stupid or broken in waiting for a service to shutdown? I mean Slackware used to send a SIGTERM to all processes, wait two seconds, and send a SIGKILL. Why would anyone need more? It's the Unix way (except it isn't). If you disagree with the default wait time then you disagree with the default wait time. So what.
    - Quekid5 6y ago
      On this particular issue I find it hard to fault them for using a (perhaps overly) safe default. Summarily killing processes with a SIGKILL should really be a last resort because it can very easily corrupt data. If you have processes which just hang for ages during shutdown, there is probably something wrong with your system (or the process's code) which might warrant further investigation.
      - floatboth 6y ago
        If your software corrupts data when it's killed, it's honestly not very good software. I kinda wish "proper shutdown" was never invented at all. That would've motivated so many developers to care about reliability much more :P
        Too 6y ago
        Flash wear and disk write ack latency would shoot up the roof for that to work unfortunately.
        floatboth 6y ago
        Only if you care deeply about always having the latest data, rather than just consistent data. I'm talking more along the lines of ZFS – I can always pull the plug without worrying about FS consistency, because the FS always goes between valid, consistent states atomically.
        kaba0 6y ago
        What about having for example libreoffice running with unsaved changes? (And I know it does backups regularly but not after every character)
        Too 6y ago
        Current generation file systems, including ext4, already have journaling to prevent this.
    - alyandon 6y ago
      /me shrugs It's just another init system to me. I don't really care enough about it to get upset and complain that I had to read some documentation and edit a text file to change its behavior.
- Nextgrid 6y ago
  This is not a systemd issue per-se. Whatever process it’s trying to stop is taking its time. Systemd doesn’t explicitly know what to do and most likely falls back to a reasonable compile-time default. The other comments already explained how to change the timeout per-unit, but I wonder how would you want a “perfect” init system to handle this? Hang forever until the process dies without any message (as far as I know this is how legacy shell-script-based inits would handle it)? Kill the process immediately and risk data loss? Behave as-is but with a lower default delay?
  - dooglius 6y ago
    The Windows behavior (prompt the user to kill anything manually) seems like the ideal behavior. Of course, this is tricky wrt dependency issues (e.g. if remote, you need to keep sshd and its dependencies alive in order to implemnent such a prompt), but hanging forever seems like a preferable fallback.
    - kaba0 6y ago
      And that is the responsibility of the display manager (and it is sort of what happens under gnome). Systemd had as default KillUserProcesses (it may not be the exact name but it was something like that, I didn’t check it) set to true, and that caused many to hate on the whole project because I don’t know tmux and other apps that override the “normal” behavior on signals lost their sessions. So now it usually defaults to false, though I tend to override it to true. The thing is, “with enough users someone will depend on both the public and private parts of your APIs” is true (and I am sure I butchered up this quote as well)
- ragnese 6y ago
  What does OpenRC do for stopping services before shutdown? Does it just have a shorter wait time by default?
  - Shared404 6y ago
    I don't know, because it hasn't come up. It's Just Worked (tm) thus far.

Shared404 6y ago

> I always found systemd to be fine (I'm not a sysadmin, just prefer Linux on my PCs). I mostly agree, although I prefer OpenRC personally. I was bit by [* ] Stopping service 1:30 remaining too many times to really like SystemD, although I tolerate it on my daily driver these days.

alyandon 6y ago
You can fix the problematic service with: systemctl edit service-name [Service] TimeoutStopSec=XX You can also override the global default DefaultTimeoutStopSec in /etc/systemd/system.conf.
- unanswered 6y ago
  See, this right here is the (technical, not social) problem with systemd. Whether anyone points out that systemd is doing something stupid and wrong, the systemd shills' answer is always "well duh what did you expect when you didn't modify one of the hundred default configuration files to have `[stupidshit] = false`! You brought this on yourself!" And you're lucky if that even works to solve the problem.
  - jamespo 6y ago
    Yes bring back the handwritten shellscripts to start up & shut down services
  - deleted 6y ago
    [deleted]
  - zorked 6y ago
    What's stupid or broken in waiting for a service to shutdown? I mean Slackware used to send a SIGTERM to all processes, wait two seconds, and send a SIGKILL. Why would anyone need more? It's the Unix way (except it isn't). If you disagree with the default wait time then you disagree with the default wait time. So what.
  - Quekid5 6y ago
    On this particular issue I find it hard to fault them for using a (perhaps overly) safe default. Summarily killing processes with a SIGKILL should really be a last resort because it can very easily corrupt data. If you have processes which just hang for ages during shutdown, there is probably something wrong with your system (or the process's code) which might warrant further investigation.
    - floatboth 6y ago
      If your software corrupts data when it's killed, it's honestly not very good software. I kinda wish "proper shutdown" was never invented at all. That would've motivated so many developers to care about reliability much more :P
      - Too 6y ago
        Flash wear and disk write ack latency would shoot up the roof for that to work unfortunately.
        floatboth 6y ago
        Only if you care deeply about always having the latest data, rather than just consistent data. I'm talking more along the lines of ZFS – I can always pull the plug without worrying about FS consistency, because the FS always goes between valid, consistent states atomically.
        kaba0 6y ago
        What about having for example libreoffice running with unsaved changes? (And I know it does backups regularly but not after every character)
        Too 6y ago
        Current generation file systems, including ext4, already have journaling to prevent this.
  - alyandon 6y ago
    /me shrugs It's just another init system to me. I don't really care enough about it to get upset and complain that I had to read some documentation and edit a text file to change its behavior.
Nextgrid 6y ago
This is not a systemd issue per-se. Whatever process it’s trying to stop is taking its time. Systemd doesn’t explicitly know what to do and most likely falls back to a reasonable compile-time default. The other comments already explained how to change the timeout per-unit, but I wonder how would you want a “perfect” init system to handle this? Hang forever until the process dies without any message (as far as I know this is how legacy shell-script-based inits would handle it)? Kill the process immediately and risk data loss? Behave as-is but with a lower default delay?
- dooglius 6y ago
  The Windows behavior (prompt the user to kill anything manually) seems like the ideal behavior. Of course, this is tricky wrt dependency issues (e.g. if remote, you need to keep sshd and its dependencies alive in order to implemnent such a prompt), but hanging forever seems like a preferable fallback.
  - kaba0 6y ago
    And that is the responsibility of the display manager (and it is sort of what happens under gnome). Systemd had as default KillUserProcesses (it may not be the exact name but it was something like that, I didn’t check it) set to true, and that caused many to hate on the whole project because I don’t know tmux and other apps that override the “normal” behavior on signals lost their sessions. So now it usually defaults to false, though I tend to override it to true. The thing is, “with enough users someone will depend on both the public and private parts of your APIs” is true (and I am sure I butchered up this quote as well)
ragnese 6y ago
What does OpenRC do for stopping services before shutdown? Does it just have a shorter wait time by default?
- Shared404 6y ago
  I don't know, because it hasn't come up. It's Just Worked (tm) thus far.