-
-
Notifications
You must be signed in to change notification settings - Fork 973
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rule "Host out of inodes" triggers false positive with FAT16 on FreeBSD #398
Comments
This commit removes the false positive alerts where a FreeBSD host has a MS-DOS based file system mounted. resolves samber#398
Can you develop please? I'm mostly a linux+macos user. In what situation is msdosfs used? |
I have this exact issue on my OPNSense firewall that is freebsd based. |
The FAT16 file system is used for the EFI partition.
My partition is indeed FAT16 and I am victim of this bug.
I hope this explains the situation. @samber, this bug will be auto-fixed in an unknown future. In the meantime a PR can easily fix it today. As the maintainer of this project it's up to you to choose what decision to take. |
The MSDOSFS code in 13.3. could be backported to 13.2, but a simpler work-around would be to just return 0 for the total number of inodes (f_files). The value 0 is typically used for synthetic file systems (procfs, devfs, ...) to indicate that they do not actually use inodes (and AFAIK, monitoring systems understand this signal and ignore the inode stats).
If this simple patch was applied to OPNSense, the "out of inodes" issue should be resolved. (A similar patch should be applied to all synthetic file systems, some of which also reported 100% inodes used. This is fixed in 13.3 and later versions, too.) |
I just made a fix and prepared a revert for 2025. |
The commit fixes the issue. Thank you. |
Hi,
I'm monitoring my OPNsense box with Node exporter. The rule
HostOutOfInodes
triggers an error with this result:{device="/dev/gpt/efiboot0", fstype="msdosfs", instance="my-opnsense-box:9100", job="node_exporter", mountpoint="/boot/efi", nodename="opn"} = 0
It should not trigger that error.
I tried to think about a generic way to resolve the query but I think the
msdosfs
fstype should be simply excluded from the query.I can provide a PR.
The text was updated successfully, but these errors were encountered: