4 ms·

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 messa

by 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'.
  - zaarn 7y ago
    >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. It saves data if you don't mash the reset button at first sight >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. Systemd won't bring down the network until all services that depends on the network have been stopped. The desktop environment doesn't unless the home directory is a NFS mount. >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. A program running as a service can override the timeout in it's unit file. >And finally, processes ignoring SIGTERM is really just one of the reasons why this happens. Correct, processes who ignore SIGTERM are the real problem, processes that take a long time are a secondary culprit. But systemd can't do much if the devs of software refuse to read documentation on signals when writing handlers for them.

by alxlaz 7y ago

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'.
- zaarn 7y ago
  >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. It saves data if you don't mash the reset button at first sight >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. Systemd won't bring down the network until all services that depends on the network have been stopped. The desktop environment doesn't unless the home directory is a NFS mount. >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. A program running as a service can override the timeout in it's unit file. >And finally, processes ignoring SIGTERM is really just one of the reasons why this happens. Correct, processes who ignore SIGTERM are the real problem, processes that take a long time are a secondary culprit. But systemd can't do much if the devs of software refuse to read documentation on signals when writing handlers for them.