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?

Improve this question
3
  • A related question is unix.stackexchange.com/q/310737/5132 .
    – JdeBP
    Apr 1, 2019 at 21:38
  • That's not a good design choice, and this is loaded question.
    – user313992
    Dec 28, 2019 at 16:26
  • User asks a rhetorical question - if the stop job and the stop-job-target are desync'd when the target is already stopped, there's no end to the stop job (it seems to even ignore /lib/systemd/*/timeoutstopSec settings). So it just spinlocks forever. Bad design choice. :)
    – math
    Mar 6 at 20:58

2 Answers 2

Reset to default
-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?

Improve this answer
4
  • 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, 2019 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, 2019 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, 2019 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, 2019 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.

Improve this answer
2
  • 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, 2019 at 18:08
  • Better try the REISUB key combination before doing this. It is safer
    – Quora Feans
    Dec 10, 2019 at 2:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .