#582 check_disk: inconsistency when given device file as -p

release-1.4.15
open
nobody
5
12 minutes ago
2012-11-27
Jonas Meurer
No

Hello,

I observed a inconstency in check_disk plugin when device files are given as argument to option -p:

On recent linux system fstab and mtab often list symlinks like '/dev/disk/by-uuid/...' as device path. The nagios plugin check_disk supports only the exact same device name as given in fstab (and listed in mtab) as argument to -p. If you give a device path like '/dev/sda1' instead of the one from fstab, the argument is not treated as device path, but instead as path to a file on mountpoint '/dev'. This should be fixed, best by using libblkid.

In Debian/Squeeze:

# mount
[...]
/dev/sda1 on / type ext4 (rw,errors=remount-ro)
udev on /dev type tmpfs (rw,mode=0755)
# /usr/local/nagios/libexec/check_disk -w 20% -c 10% -p /
DISK OK - free space: / 68787 MB (85% inode=99%);| /=11402MB;67585;76033;0;84482
# /usr/local/nagios/libexec/check_disk -w 20% -c 10% -p /dev/sda1
DISK OK - free space: / 68787 MB (85% inode=99%);| /=11402MB;67585;76033;0;84482
# /usr/local/nagios/libexec/check_disk -w 20% -c 10% -p /dev
DISK OK - free space: /dev 36312 MB (99% inode=99%);| /dev=0MB;29049;32680;0;36312

in Debian/Wheezy (another system):

# mount
[...]
/dev/disk/by-uuid/********** on / type ext4 (rw,relatime,errors=remount-ro,user_xattr,barrier=1,data=ordered)
udev on /dev type devtmpfs (rw,relatime,size=10240k,nr_inodes=3090668,mode=755)
# /usr/local/nagios/libexec/check_disk -w 20% -c 10% -p /
DISK CRITICAL - free space: / 16313 MB (7% inode=99%);| /=200808MB;182992;205866;0;228741
# /usr/local/nagios/libexec/check_disk -w 20% -c 10% -p /dev/sda1
DISK OK - free space: /dev 10 MB (100% inode=99%);| /dev=0MB;8;9;0;10
# /usr/local/nagios/libexec/check_disk -w 20% -c 10% -p /dev
DISK OK - free space: /dev 10 MB (100% inode=99%);| /dev=0MB;8;9;0;10

I verified that the same nagiosplugins 1.4.15 source was compiled on both systems. Only difference is the underlying Debian release. I guess that some shared library or kernel changes triggered this bug.

Kind regards,
Jonas Meurer

Discussion