Carlos E. R. wrote:
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.
I don't understand a word of that ? You have one process which disabled interrupts whilst in some bit of kernel code, maybe a driver, who knows. Disabling interrupts just means a bit of code that must complete without any asynchronous calls happening. Most probably to guarantee data integrity. It's perfectly normal. -- Per Jessen, Zürich (13.4°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org