4 ms·

I agree that systemd gets way more hate than it deserves, but it has continual problems on Arch Linux. Wherever you try to shutdown without logging out first, s

I agree that systemd gets way more hate than it deserves, but it has continual problems on Arch Linux. Wherever you try to shutdown without logging out first, systemd says ”a stop job is running for user manager...", then waits 90 seconds. The issue keeps getting fixed, then resurfacing. People with this same problem are all over the internet.

zaarn 7y ago
In my experience, that happens when a user process is ignoring the SIGTERM signal (ie, a word process or browser wanting user confirmation before shutting down). Generally, I personally don't mind it and I set the timeout to 30 seconds, which helps. There is probably no good solution unless systemd starts to send SIGKILL instead of SIGTERM to kill without questioning why, but that would break everything else.
- mongol 7y ago
  Maybe there should be hard and soft shutdowns? Or maybe there already is?
  - zaarn 7y ago
    SysRq-b is a hard shutdown. "Soft" vs "Hard" isn't a realistic distinction, systemd already does a "hard" shutdown if the timeout is exceeded. There is no reason to do a hard one in any system, a soft shutdown is always preferable as things like database engines might need a moment to save their data. If you send them a SIGKILL then your database engine will loose data.
- stuaxo 7y ago
  I get this every time I shut down. The GUI has shutdown a while before, but I have to hold the power button down every time I shut down my laptop. TBH it's not as bad, as suspend being broken because it's a ryzen based laptop. (Half the time it comes back with a black screen and I have to hard reboot).
  - zaarn 7y ago
    The GUI shuts down but the process of the app usually keeps running. It's not unusual that I see firefox being waited on.
- boring_twenties 7y ago
  If he's seeing that message, he's already at the console which means that the X server has been shut down.
  - zaarn 7y ago
    Plenty of apps will keep running, atleast from what I see, the console is up and usually waiting for firefox to close (which is waiting for the confirmation dialog).
    - throwaway8941 7y ago
      It should register itself as an inhibitor then. Systemd won't let you shut down the system as long as there are inhibitors active (you can still force it). As desktop Linux users we should consider it to be a bug in Firefox (among others). See $ systemd-inhibit --list https://www.freedesktop.org/wiki/Software/systemd/inhibit/ https://www.freedesktop.org/wiki/Software/systemd/inhibit/ Cue "applications-shouldn't-depend-on-systemd-we-need-350-competing-init-systems" folk.
      - zaarn 7y ago
        It'll probably take some time for desktop apps to register as inhibitor. KeepassXC has done this IIRC so now if systemd tries to shutdown with an unsaved database, you can't. Various other desktop apps do too these days, so it's largely a question of time.
    - boring_twenties 7y ago
      What do you mean, exactly? Does the X server stay running after you're already looking at the console? Or does Firefox stay running after the X server is already gone?
      - zaarn 7y ago
        Firefox keeps running after X is gone and waits for me to confirm to close all windows.
- alxlaz 7y ago
  Just to play devil's advocate: prior to systemd, nobody had this problem. In 20 years of Unices I can't remember a single time when I couldn't shut down my machine because a user process was ignoring SIGTERM (or really, because a user process was doing something). I'm not sure what "everything else" there is to break... I actually enjoy the extra flexibility that I get out of being able to tell systemd how to terminate processes. On the systems I'm building. But it's something that could certainly be improved. It works right for my use case (embedded systems) but I hate it when it does it on my laptop or my home machine. The whole interface around it is silly. It tells you that a job is running, but it doesn't tell you what that job is, what that process is, and unless you enable the debug shell, there's no way to check it or kill that process either. All you get to is stare at the thing counting down from 90, and in some cases when it reaches 0, it starts counting down again instead of rebooting.
  - zaarn 7y ago
    Well, before it wasn't a problem, largely because the init system just murdered everything that didn't drop dead when told to (ie, your desktop apps will be SIGTERM'd along with the X Server). Systemd certainly takes a more safe approach. Atleast in my experience, systemd certainly tells you what is hanging. The issue with "timer reset" is that some service that is hanging is also blocking some other service from shutting down (either because the hanging service depends on it or the blocked service needs to be shut down after the hanging service). Old Init systems didn't care either, if the system was to shut down, it just killed in order of runlevel so stuff like "The database was corrupted because init forcibly killed the NFS mount too early" was certainly possible.
    - y4mi 7y ago
      i think the source of the hate is how little the dialog actually tells the user. imagine the message saying something like "{{ process_name || process_command }} is blocking the shutdown, press F7 to terminate it forcefully" i doubt anyone would complain about systemd with such a message. its just beyond annoying not being able to see which application is causing the issue nor having any options beyond waiting or removing the power entirely
haecceity 7y ago
People shutdown their computers?
- viraptor 7y ago
  This is arch. You're likely getting at least one kernel update a month. That requires a restart which involves a shutdown. (Unless you're into kexec magic)
JdeBP 7y ago
Back in 2017 there was a person on Twitter who was collecting every time that one of his machines had a systemd shutdown problem. * https://news.ycombinator.com/item?id=15896376 https://news.ycombinator.com/item?id=15896376 Machine shutdown is one of the parts of service management that often does not get enough attention.

zaarn 7y ago

In my experience, that happens when a user process is ignoring the SIGTERM signal (ie, a word process or browser wanting user confirmation before shutting down). Generally, I personally don't mind it and I set the timeout to 30 seconds, which helps. There is probably no good solution unless systemd starts to send SIGKILL instead of SIGTERM to kill without questioning why, but that would break everything else.

mongol 7y ago
Maybe there should be hard and soft shutdowns? Or maybe there already is?
- zaarn 7y ago
  SysRq-b is a hard shutdown. "Soft" vs "Hard" isn't a realistic distinction, systemd already does a "hard" shutdown if the timeout is exceeded. There is no reason to do a hard one in any system, a soft shutdown is always preferable as things like database engines might need a moment to save their data. If you send them a SIGKILL then your database engine will loose data.
stuaxo 7y ago
I get this every time I shut down. The GUI has shutdown a while before, but I have to hold the power button down every time I shut down my laptop. TBH it's not as bad, as suspend being broken because it's a ryzen based laptop. (Half the time it comes back with a black screen and I have to hard reboot).
- zaarn 7y ago
  The GUI shuts down but the process of the app usually keeps running. It's not unusual that I see firefox being waited on.
boring_twenties 7y ago
If he's seeing that message, he's already at the console which means that the X server has been shut down.
- zaarn 7y ago
  Plenty of apps will keep running, atleast from what I see, the console is up and usually waiting for firefox to close (which is waiting for the confirmation dialog).
  - throwaway8941 7y ago
    It should register itself as an inhibitor then. Systemd won't let you shut down the system as long as there are inhibitors active (you can still force it). As desktop Linux users we should consider it to be a bug in Firefox (among others). See $ systemd-inhibit --list https://www.freedesktop.org/wiki/Software/systemd/inhibit/ https://www.freedesktop.org/wiki/Software/systemd/inhibit/ Cue "applications-shouldn't-depend-on-systemd-we-need-350-competing-init-systems" folk.
    - zaarn 7y ago
      It'll probably take some time for desktop apps to register as inhibitor. KeepassXC has done this IIRC so now if systemd tries to shutdown with an unsaved database, you can't. Various other desktop apps do too these days, so it's largely a question of time.
  - boring_twenties 7y ago
    What do you mean, exactly? Does the X server stay running after you're already looking at the console? Or does Firefox stay running after the X server is already gone?
    - zaarn 7y ago
      Firefox keeps running after X is gone and waits for me to confirm to close all windows.
alxlaz 7y ago
Just to play devil's advocate: prior to systemd, nobody had this problem. In 20 years of Unices I can't remember a single time when I couldn't shut down my machine because a user process was ignoring SIGTERM (or really, because a user process was doing something). I'm not sure what "everything else" there is to break... I actually enjoy the extra flexibility that I get out of being able to tell systemd how to terminate processes. On the systems I'm building. But it's something that could certainly be improved. It works right for my use case (embedded systems) but I hate it when it does it on my laptop or my home machine. The whole interface around it is silly. It tells you that a job is running, but it doesn't tell you what that job is, what that process is, and unless you enable the debug shell, there's no way to check it or kill that process either. All you get to is stare at the thing counting down from 90, and in some cases when it reaches 0, it starts counting down again instead of rebooting.
- zaarn 7y ago
  Well, before it wasn't a problem, largely because the init system just murdered everything that didn't drop dead when told to (ie, your desktop apps will be SIGTERM'd along with the X Server). Systemd certainly takes a more safe approach. Atleast in my experience, systemd certainly tells you what is hanging. The issue with "timer reset" is that some service that is hanging is also blocking some other service from shutting down (either because the hanging service depends on it or the blocked service needs to be shut down after the hanging service). Old Init systems didn't care either, if the system was to shut down, it just killed in order of runlevel so stuff like "The database was corrupted because init forcibly killed the NFS mount too early" was certainly possible.
  - y4mi 7y ago
    i think the source of the hate is how little the dialog actually tells the user. imagine the message saying something like "{{ process_name || process_command }} is blocking the shutdown, press F7 to terminate it forcefully" i doubt anyone would complain about systemd with such a message. its just beyond annoying not being able to see which application is causing the issue nor having any options beyond waiting or removing the power entirely

haecceity 7y ago

People shutdown their computers?

viraptor 7y ago
This is arch. You're likely getting at least one kernel update a month. That requires a restart which involves a shutdown. (Unless you're into kexec magic)

JdeBP 7y ago

Back in 2017 there was a person on Twitter who was collecting every time that one of his machines had a systemd shutdown problem. * https://news.ycombinator.com/item?id=15896376 https://news.ycombinator.com/item?id=15896376 Machine shutdown is one of the parts of service management that often does not get enough attention.