On Sat, 21 Mar 2020 20:38:05 +0100 (CET) "Carlos E. R." <robin.listas@telefonica.net> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Content-ID: <alpine.LSU.2.21.2003212026470.10293@Legolas.valinor>
El 2020-03-21 a las 14:41 -0000, Dave Howorth escribió:
On Sat, 21 Mar 2020 12:37:23 +0100 Per Jessen <per@computer.org> wrote:
Dave Howorth wrote:
On Sat, 21 Mar 2020 09:28:41 +0100 Per Jessen <per@computer.org> 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".
OK, I think the difficulty we've had is that you've been using the word 'interrupt' when you should have been using the word 'signal'.
Yes, when I think of interrupt I do of the pin in the CPU with that name. With variations: a single one, or one normal and another that can not be masked, or numbered interrupts by writing a number in some bus, specific or not, at the same time of after lifting the IRQ line. Not of the strange concept that Microsoft used in MsDos with numbered software interrupts, with support from the CPU. Could have been called predefined subrutiine table or something. It confuses the hell out of me, sorry.
That's the correct word according to https://www.gnu.org/software/libc/manual/html_node/Termination-Signals.html where it also notes:
"In fact, if SIGKILL fails to terminate a process, that by itself constitutes an operating system bug which you should report."
So I think Carlos should open a bugzilla.
Ok, will do, thanks, if the log survived. The machine is being migrated, so the log may be in the new or the old machine, dunno. I can't access it now.
Plus as Carlos says, since when has a network connection disappearing been unexpected and have any effect on data integrity?
A network filesystem mount ?
I have a number of systems running with root on NFS, root is always mounted with "hard,intr". That means "wait forever" in the case of loss of the connection.
But in that case the mount is not done by a user program (mc in Carlos' case) via FUSE
A FUSE driver also has to use kernel services.
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.
Yes, but that's the wrong answer. It might have been the remote system broke or was destroyed, for example, so it cannot be restored. And it's not what Carlos wants anyway. He wants his system to hibernate. And specifically he wants to be able to kill the mc process. Maybe he's assessed any data integrity issues and decided he doesn't care, or at least that it's the least worst option.
There is no filesystem data integrity issue, from my point of view. The terminal where mc was "running" had not been used for hours. There was no activity.
The use case is simply I was going to sleep, I was sleepy already, and not in the mood to fight a computer refusing to hibernate for 3 times in a row, getting cold in my pijamas. So I issue the command on both machines, as nearly the same time as keyboarding the command on both. The new machine is faster and I typed there first, anyway, so it went down fast.
Meaning, at that time I'm not considering remembering what network connections I may have opened. In fact, it is very possble there are ssh sessions in any direction. I never care about them, unless I want the history to be saved, I just hibernate. The next day the sessions are duly dead.
Consider a laptop and clossing the lid. Would it be acceptable it not going to sleep inmediately, and running the battery out? The kernel has to suspend the machine no matter what, no excusses accepted. What if the laptop goes into the backback and then catches fire? I'm not imagining things, it has happened, albeit with Windows in the cases I heard.
It is not acceptable that a machine does not hibernate on order.
Exactly so.
- -- Cheers Carlos E. R.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org