Hacker News Reader

Comment by eptcyka | Hacker News Reader

For me, it's a benchmark of a well made system - the lower bandwidth of log output you get when a user machine is idling, the better. I have seen some Android phones produce megabytes of logs just sitting there - you can test this by running `<whatever command outputs logs> | pv`.

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.

View on HN

This, plus on MacOS 'faults' specifically indicate events where the computer could not gracefully recover, so some user noticeable thing happened.

e.g. when the WiFi adaptor faults and has to restart.

No, it's just the highest severity log and stays archived the longest. (And records a backtrace.)

It doesn't mean anything besides that though.

Source?

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.

My system's running fine with no noticeable issues. I opened Console to check for faults and after running with logging on I eventually got a couple, all tied to Safari trying to read a preference from a domain it didn't have permissions to. No performance issues or other user-detectable impacts.

'Safari trying to read a preference from a domain it didn't have permissions to.'

That doesn't sound like normal behaviour, what's the domain?

It looks like a plug-in hitting some Preferences path it doesn't need to read as it iterates for its pref.

The literal source code in this case: you can look up yourself how os_log_fault works.

Can you link it?

  #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.

This doesn't seem to indicate what you suggest. Can you link proof that even a single real world application calls it whenever it wants?

The mere fact that it's theoretically possible doesn't seem to be persuasive.

On the contrary, I find your position to be confusing. It's just a function that anyone can call. If you go on GitHub you can see many people who are using it for whatever logging they think is appropriate. Why do you think it has anything to do with correctness? This isn't like a crash or a OOM where you're generally pretty sure something is seriously wrong, because you can just trigger this whenever you want.

Then it would only take you a minute to link an example or two?

By this metric, they could vastly improve system quality by reducing log verbosity.

Of course, if you take the cynical approach to optimising software, you can easily ruin the utility of this metric quickly.

Reply on news.ycombinator.com