Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2020-03-21 a las 12:37 +0100, Per Jessen escribió:
Dave Howorth wrote:
...
Ah, I think I understand. When the term 'interrupt' is used, Carlos and I think of a hardware capability. I gather you're thinking of an emulated software capability.
Yes, I'm looking at it as being "sat" inside a process. Hardware interrupts are usually not serviced by a process (kernel or user), but by an interrupt handler which then queues whatever it is (for processing). (I'm not sure how HPET interrupts are handled though).
Carlos' 'midnight commander' is just a process, accessing the fuse filesystem that is mounted with sshfs. As it has disabled SIGKILL, it must be in kernel mode. I think disabling SIGKILL can only be interpreted to mean "this _must_ complete, to avoid corrupting data".
If the connection dies, it dies. So, end the whatever is doing no matter what, there is no recovering.
You're guessing. What you describe works perfectly fine with NFS, for instance.
Going back to the very first post, I think the situation could have been remedied by resuming the machine at 192.168.1.134. Now Carlos' 'mc' would have been able to complete the "must complete" code and exit cleanly.
That's a terrible solution. In this case, I might have done it. What if the other machine is remote?
Unless you have a way of waking it up remotely, don't hibernate it. -- Per Jessen, Zürich (8.0°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org