3

In a typical modern Linux distribution, the user may experience this when trying to shut down the computer:

A stop job is running for Session c2 of user, or equivalent.

I understand the idea behind this: the operating system sends SIGTERM, I suppose, to the program, and it doesn't terminate.

I suppose that sending SIGKILL is safer, less of a chance that data is lost for a program that manages to clean up after itself and stop gracefully.

Regression

  • You can change some timeouts, shutdown in a different way.
  • There isn't a key combination you can punch in, if you as a user want to override this, like control + D, or control + C to cancel it and just send SIGKILL immediately.

I hope there is some logical reasoning behind this design choice, because to me, it seems awfully similar to how e.g. Windows deals with a process that isn't "responding" and seems very inspired from that. Why is there no way to just stop this A stop job is running for Session c2 of user waiting for timeout message?

-1

Given the timeout values being too large, it isn't.

But you have plenty of time to spin up a USB drive with a SWAP file or whatever was the reason for the deadlock. For many users, if by second 60 the machine still runs, any more waiting is just a waste of life time. Though reports indicate a termination of os-prober after full 6 minutes, by wich time, however, 1:30 min had run out, so that timeout was too short. Tricky, no?

  • I fail to see even this as justification. This design choice treats the user as an unintelligent piece of trash. Not only is there no way to terminate the offending process, the system doesn't even provide the user with information regarding what process is blocking the shutdown sequence. If it was indeed a USB drive waiting for syncing, that would be very useful -- it might prevent me from hitting the power switch in anger. And what does the os-prober have to do with this? – AlphaCentauri Dec 10 '19 at 13:46
  • os-prober just mentioned as a real-world example of such deadlock. to find out the offender, use Ctrl-Alt-F9 debug shell "htop" following a recent post of mine: "dreaded cylon..." at unix.stackexchange.com/questions/556196/… – dotbit Dec 10 '19 at 13:50
  • I don't agree. Spinning up a new shell to deal with this is not a good idea, it takes extra effort and time to manually list processes using other utilities and tools and essentially debug a failed system. What it should be doing, is present a simple menu to the user of intuitive options to choose from while still showing the timeout as usual. Explain to the user exactly what the problem is, what the process is, then list that you can either wait, or kill it now, and explain with one simple sentence that there might be risks of data loss and/or corruption involved. – AlphaCentauri Dec 10 '19 at 13:52
  • sure, ideally the famous systemD ought to perform that functionality right away. I assume, the various deadlock scenarios are just too numerous and varied to treat them with a few pages of C++ code. – dotbit Dec 10 '19 at 13:54
-3

There is a hardware solution for this. If you really don't want to wait to allow the system to try to shutdown gracefully, you can always hold he power button down for a few seconds. I've done this a few times when the timeout just gets longer and longer.

  • 1
    This is not an answer. It's just a crude hack work-around to get your computer to shutdown when you encounter this type of systemd hang, which is itself the result of bad design and implementation. The question is if there is a way to resolve this problem in a clean way that is not a crude hardware shutdown. – Lizardx Apr 1 '19 at 18:08
  • Better try the REISUB key combination before doing this. It is safer – Quora Feans Dec 10 '19 at 2:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.