>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

>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.