29 Dec
2021
29 Dec
'21
10:58 p.m.
(Moving to COFF, tuhs on bcc.)
On Tue, Dec 28, 2021 at 01:45:14PM -0800, Greg A. Woods wrote:
If recall correctly, the last time someone tried to submit patches,
they overloaded some signal that was in use, and it was NACK'ed on
that basis. I personally didn't care, because on my systems, I'll use
GUI program like xload, or if I need something more detailed, GKrellM.
(And GKreelM can be used to remotely monitor servers as well.)
It's used in Solaris to report that the client NFSv4 code could not
recover a file lock on recovery. So that means one of the first
places to look would be to see if Ganesha (an open-source NFSv4
user-space client) isn't using SIGLOST (or might have plans to use
SIGLOST in the feature).
For a remote / distributed file system, Brewer's Theorem applies
--- Consistency, Availability, Partition tolerance --- chose any
two, but you're not always going to be able to get all three.
Cheers,
- Ted
There have
been patches proposed, but it turns out the sticky wicket
is that we're out of signal numbers on most architectures.
Huh. What an interesting "excuse"! (Not that I know anything useful
about the implementation in Linux....) SIGLOST
- Term File lock lost (unused)
SIGSTKFLT - Term Stack fault on coprocessor (unused)
If SIGLOST were used/needed it would seem like a very bad system design.