Don't pollute the logs with some errors #6518
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Prompted by a round of manual testing at Vates, where a lot of new starters installed new ISOs and were met with a barrage of errors they couldn't possibly know are critical or not :) Will try to follow up with a few more cases, but the general motivation is to keep at least the first known-good installation error-free in the logs... |
lindig
approved these changes
Jun 10, 2025
edwintorok
reviewed
Jun 10, 2025
| in | ||
| let conf_files = Array.to_list (Sys.readdir conf_dir) in | ||
| let conf_files = | ||
| try Array.to_list (Sys.readdir conf_dir) with Sys_error _ -> [] |
There was a problem hiding this comment.
Might be better to explicitly check for the existence of the directory first, unfortunately Sys.* functions aren't very good at error handling because you can't distinguish between a failure due to the directory not being present and a failure that you don't have permission to read it, or a genuine I/O error.
edwintorok
reviewed
Jun 10, 2025
edwintorok
reviewed
Jun 10, 2025
last-genius
force-pushed
the
asv/improve-logging
branch
from
da6d648 to
aec8803
Compare
Signed-off-by: Andrii Sultanov <[email protected]>
on every toolstack restart on hosts without Nvidia GPUs, xapi complains about a
non-existent directory:
xapi: [error||0 |dbsync (update_env) R:733fc2551767|xapi_vgpu_type]
Failed to create NVidia compat config_file: Sys_error("/usr/share/nvidia/vgx: No such file or directory")
Handle the directory's absence without propagating the error.
Signed-off-by: Andrii Sultanov <[email protected]>
…_line Otherwise this quite frequently logs something like: ``` xcp-networkd: [error||22 |dbsync (update_env)|network_utils] Error in read one line of file: /sys/class/net/eth0/device/sriov_totalvfs, exception Unix.Unix_error(Unix.ENOENT, "open", "/sys/class/net/eth0/device/sriov_totalvfs") Backtrace ... ``` Signed-off-by: Andrii Sultanov <[email protected]>
non_debug_receive will dump an error after reading the last bits of the header, which is expected and handled by the caller appropriately: ``` xenopsd-xc: [error||67 |Async.VM.resume R:beac7be348f1|xenguesthelper] Memory F 6019464 KiB S 0 KiB T 8183 MiB <--- dumping error xenopsd-xc: [debug||67 |Async.VM.resume R:beac7be348f1|mig64] Finished emu-manager result processing <---- End_of_file expected and handled ``` Don't pollute the logs and instead just log the same info with 'debug' when the error is End_of_file. Signed-off-by: Andrii Sultanov <[email protected]>
last-genius
force-pushed
the
asv/improve-logging
branch
from
aec8803 to
3f0e977
Compare
psafont
approved these changes
Jun 11, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
It's an in-house joke that most of
xapi's errors are "expected" (either because they're handled by the caller after being logged or because they are frequent and benign) and knowing which ones are unusual and actually critical takes a lot of learning. Try to remove at least some of the most obvious ones from the toolstack startup/VM resume, either removing the logs completely or downgrading it todebugwhen appropriate.Manually tested in the appropriate scenarios.