3 ms·

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 mach

by 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
- alxlaz 7y ago
  Edit: first and foremost -- sorry, I went on a trip down the memory lane because you mentioned NFS and I forgot to mention the most important point. That message, and this approach, is 100% inconsequential, and it doesn't make anything safer. IIRC, last time I checked, virtually none of the distributions enable the systemd debug shell. If you see that message, you can't stop the application manually. Ctrl-Alt-Del doesn't work, either, and if systemd can't recover from that state -- which, depending on what's actually happening and on the configuration, it sometimes can't -- all you get to do is press the reset button anyway. If an application is hung for a legitimate reason, like, there's unsaved work, you can't go back and save it anyway. All you can do is wait for 30 seconds for the system to reboot and lose the data anyway (just 30 seconds later). That aside, I've debugged my fair share of corruption, back when journaling filesystems were new and NFS was way worse than it is today. I don't want to go back to those days, either, and I'm glad to have a safety switch for sensitive setups, or for misbehaving/legacy applications. But no one has a problem with that. People have a problem when they don't have anything mounted over NFS (that, by the way, is also something that occasionally caused systemd to hang at one point) and still can't reboot their machine. It's not like we had to wait until 2010 to figure out that init systems need to handle these things carefully. Nobody compares this behaviour with the golden age of Ultrix and says oh, right, thank God for this, it's a minor inconvenience but at least my files are safe. Everybody compares this with what's available on every other platform that's popular today, not in 1996 -- namely a "Force reboot" button that reboots your machine and virtually never results in data loss.
  - mlyle 7y ago
    > it doesn't make anything safer Why does a program given SIGTERM not quit? Is it because 1) it's still busy desperately trying to save something large and unusual or over a network, 2) it's antisocial and ignores SIGTERM, or 3) it's hung for some permanent reason? It's hard to tell from the outside. Most of the time it's the second or third, but the behavior occasionally saves data in the first case.
    - alxlaz 7y ago
      I mean... yes, in theory that would be the case but that's really not what's happening in this particular case. (Edit: Firstest of all, actually, more often than not it's actually 4) the program is waiting for a user's confirmation, or requires some user action to exit, but if you see that message, you can't do it anymore.) First of all, not being able to distinguish between these three cases is precisely what makes virtually everyone who's seen this a couple of time hit the reset button as soon as they see it. That doesn't save any data. Second, if a program is really busy desperately trying to save something large and unusual over a network and you see that message, there's a good chance it won't be able to save anything anyway. The network is usually down by that time, for example. There's also no way for a program to signal that it's done. If, indeed, a program needed one more second to write everything, it's cool, but you still get to wait 29 more seconds. And finally, processes ignoring SIGTERM is really just one of the reasons why this happens. I think all of us in the FOSS community should be more charitable when discussing these things. systemd is a big step ahead but it's not like we had to wait until 2010 to figure out that init systems have to tread carefully during shutdown to avoid data corruption. Also, people who read HN usually understand that killing processes can cause data corruption under some circumstances. Just sayin'.

by alxlaz 7y ago

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
alxlaz 7y ago
Edit: first and foremost -- sorry, I went on a trip down the memory lane because you mentioned NFS and I forgot to mention the most important point. That message, and this approach, is 100% inconsequential, and it doesn't make anything safer. IIRC, last time I checked, virtually none of the distributions enable the systemd debug shell. If you see that message, you can't stop the application manually. Ctrl-Alt-Del doesn't work, either, and if systemd can't recover from that state -- which, depending on what's actually happening and on the configuration, it sometimes can't -- all you get to do is press the reset button anyway. If an application is hung for a legitimate reason, like, there's unsaved work, you can't go back and save it anyway. All you can do is wait for 30 seconds for the system to reboot and lose the data anyway (just 30 seconds later). That aside, I've debugged my fair share of corruption, back when journaling filesystems were new and NFS was way worse than it is today. I don't want to go back to those days, either, and I'm glad to have a safety switch for sensitive setups, or for misbehaving/legacy applications. But no one has a problem with that. People have a problem when they don't have anything mounted over NFS (that, by the way, is also something that occasionally caused systemd to hang at one point) and still can't reboot their machine. It's not like we had to wait until 2010 to figure out that init systems need to handle these things carefully. Nobody compares this behaviour with the golden age of Ultrix and says oh, right, thank God for this, it's a minor inconvenience but at least my files are safe. Everybody compares this with what's available on every other platform that's popular today, not in 1996 -- namely a "Force reboot" button that reboots your machine and virtually never results in data loss.
- mlyle 7y ago
  > it doesn't make anything safer Why does a program given SIGTERM not quit? Is it because 1) it's still busy desperately trying to save something large and unusual or over a network, 2) it's antisocial and ignores SIGTERM, or 3) it's hung for some permanent reason? It's hard to tell from the outside. Most of the time it's the second or third, but the behavior occasionally saves data in the first case.
  - alxlaz 7y ago
    I mean... yes, in theory that would be the case but that's really not what's happening in this particular case. (Edit: Firstest of all, actually, more often than not it's actually 4) the program is waiting for a user's confirmation, or requires some user action to exit, but if you see that message, you can't do it anymore.) First of all, not being able to distinguish between these three cases is precisely what makes virtually everyone who's seen this a couple of time hit the reset button as soon as they see it. That doesn't save any data. Second, if a program is really busy desperately trying to save something large and unusual over a network and you see that message, there's a good chance it won't be able to save anything anyway. The network is usually down by that time, for example. There's also no way for a program to signal that it's done. If, indeed, a program needed one more second to write everything, it's cool, but you still get to wait 29 more seconds. And finally, processes ignoring SIGTERM is really just one of the reasons why this happens. I think all of us in the FOSS community should be more charitable when discussing these things. systemd is a big step ahead but it's not like we had to wait until 2010 to figure out that init systems have to tread carefully during shutdown to avoid data corruption. Also, people who read HN usually understand that killing processes can cause data corruption under some circumstances. Just sayin'.