On 20/03/2020 16.25, Dave Howorth wrote:
On Fri, 20 Mar 2020 13:21:17 +0100 Per Jessen <> wrote:
Carlos E. R. wrote:
On Friday, 2020-03-20 at 14:12 +0300, Andrei Borzenkov wrote:
The user run application 'mc' (Midnight Commander) was blocking hibernation (and now I see there was another application named 'pool').
I tried to kill 'mc' with killall -9. It still refused. I killed the terminal that had it, no way. In the end, I had to poweroff the machine instead.
I think that mc was blocked because it had open a remote directory externally:
sshfs cer@192.168.1.134:/ ~/fusermount/
and that other machine had been hibernated a minute before.
How can it be that a plebeian app stops the almighty kernel in its tracks?
Both threads are in kernel mode and as you yourself said cannot be interrupted. So there is little kernel can do.
Sorry, I still do not understand why a user process such as mc can not be destroyed on order. No excuses.
A user process can enter kernel mode - this one did, and then disabled interrupts. I.e. it has to complete.
Disabled interrupts? But all the processes were working, only this one was stuck. My training said that when interrupts were disabled, noone got access to them.
It sounds like a pretty severe bug to enter kernel mode, disable interrupts and then wait for some network event? And indeed a problem in the overall system architecture if it permits of such bugs!
Or am I missing something?
Same here. I still think the kernel should have control of everything, destroy all resources assigned to the process, and of course, keep the power to hibernate. If a process can't, ask the user. Ok, f**k that process. And then, there was the issue that apparently caused this: mc had a directory opened, that happened to be a remote directory. The other machine had hibernated and thus dissapeared from the network. Why be stuck as unkillable? It is a normal life occurrence, for another computer to disappear. The local process should still respond, even if the remote machine is gone and not responding. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)