(Moving to COFF, tuhs on bcc.)
On Tue, Dec 28, 2021 at 01:45:14PM -0800, Greg A. Woods wrote:
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....)
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.)
- 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.
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.