It's also a good metric to signal an anomaly after a deployment. On my desktop machines, the current culprit for most of the logs is pipewire/alsa, generating multiple lines per second.
e.g. when the WiFi adaptor faults and has to restart.
It doesn't mean anything besides that though.
Maybe in some scenarios it shows a fault that is absolutely unnoticeable, but every real world case I've seen was at least theoretically noticeable by the user.
That doesn't sound like normal behaviour, what's the domain?
#define os_log_fault(log, format, ...) \
os_log_with_type(log, OS_LOG_TYPE_FAULT, format, ##__VA_ARGS__)
It's literally just an os_log with the "fault" type set. You can call it whenever you want. Most libraries have a couple sprinkled in for things that someone should probably check at some point but there is no actual semantics to it to mean that something is necessarily broken.The mere fact that it's theoretically possible doesn't seem to be persuasive.
Just saying random things in response to a comment is not the typical HN norm.
Otherwise the default choice is to not write a comment.
My Macs stay up for months and have since Jaguar days. I use them for around 7-8 years, after that hardware starts to glitch or get obsolete. I can count on one hand the number of kernel panics I’ve had on each during this time.
I installed the most recent update five days ago, would have been weeks since the last reboot. From my experience, I'd probably put it down to some software they've installed, or yes, possibly an actual hardware fault with that particular unit.
The number of log entries shown in the console is overwhelming. All the background services constantly log ~100 messages per second, so the log entries you are looking for disappear immediately.
You can use the search filters to narrow down messages if you know what you are looking for, but if you don't already have a suspicion where the problem is coming from, then the macOS logs are close to useless.