[Nagiosplug-devel] [ nagiosplug-Bugs-3552849 ] check_disk confused by LOFS mounts

[SourceForge.net]

Bugs item #3552849, was opened at 2012-07-31 16:23
Message generated for change (Tracker Item Submitted) made by calestyo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552849&group_id=29880

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Cálestyo (calestyo)
Assigned to: Nobody/Anonymous (nobody)
Summary: check_disk confused by LOFS mounts 

Initial Comment:
Hi.

This is from the old / soon to be disabled again Nagios Plugins bug tracker that used to be at Nagios itself.
I've just copied this bug over. I'm not the original reporter and have no idea about the thoughts about this bug.

This used to be: http://tracker.nagios.org/view.php?id=186
--------------------------------------------------------------------------------
morven:
--------------------------------------------------------------------------------
check_disk takes a path with the -p option that can be either a filesystem mount path OR a device. It assumes that if it can find it in the mounted filesystems as the source of a filesystem, it's a device path, otherwise it's a mountpoint.

This is broken by LOFS on Solaris. LOFS (loopback file system) puts the source directory of the loopback as its device. Thus, the LOFS mount is chosen over the real filesystem.

This wouldn't be a real problem normally, since the usage statistics for the loopback mount are the same as the real filesystem underneath.

However, if the LOFS mount is made in a child zone, non-root processes in the parent global zone cannot statvfs() it, and the checks fail.

It would be nice to have a flag that forces interpretation as one or the other, or for the code to fall back to the alternate interpretation if the statvfs() fails, or for the code to check mnttab to see if the path is also a mount point before deciding to use the path as the device entry. 

--------------------------------------------------------------------------------
jedblack:
--------------------------------------------------------------------------------
add me to the list -- i'm having the same issue. We have Solaris global zone and a few sparse-root zones within it.

Solaris 10 global with a few spart-root zones.

here is the grep for /usr on the /etc/mnttab


bash-3.00# cat /etc/mnttab |grep -i usr
/dev/dsk/c0t2d0s4 /usr ufs rw,intr,largefiles,logging,xattr,onerror=panic,dev=d80144 1283285554
/usr/lib/libc/libc_hwcap2.so.1 /lib/libc.so.1 lofs dev=d80144 1283285553
/usr /zones/www/root/usr lofs ro,nodevices,nosub,dev=d80144 1283285653
/zones/www/root/usr/lib/libc/libc_hwcap2.so.1 /zones/www/root/lib/libc.so.1 lofs zone=www-zone,dev=d80144 1283285657
/usr /zones/k2proc/root/usr lofs ro,nodevices,nosub,dev=d80144 1283286256
/zones/k2proc/root/usr/lib/libc/libc_hwcap2.so.1 /zones/k2proc/root/lib/libc.so.1 lofs zone=k2proc,dev=d80144 1283286258
bash-3.00#
------------------------------------
And here is a df -h....

/dev/dsk/c0t2d0s0 3.9G 380M 3.5G 10% /
/devices 0K 0K 0K 0% /devices
ctfs 0K 0K 0K 0% /system/contract
proc 0K 0K 0K 0% /proc
mnttab 0K 0K 0K 0% /etc/mnttab
swap 4.5G 564K 4.5G 1% /etc/svc/volatile
objfs 0K 0K 0K 0% /system/object
/dev/dsk/c0t2d0s4 3.9G 781M 3.1G 20% /usr
/usr/lib/libc/libc_hwcap2.so.1
                       3.9G 781M 3.1G 20% /lib/libc.so.1
fd 0K 0K 0K 0% /dev/fd
/dev/dsk/c0t2d0s5 3.9G 2.6G 1.3G 68% /var
swap 4.5G 48K 4.5G 1% /tmp
swap 4.5G 24K 4.5G 1% /var/run
/dev/dsk/c0t3d0s1 56G 154M 55G 1% /weblogs
/dev/dsk/c0t2d0s7 42G 12G 29G 29% /zones
/dev/dsk/c0t2d0s6 9.9G 1012M 8.8G 11% /export/home
-bash-3.00$


now if I try to run "check_disk" as user 'nagios' on the solaris global, checking ' /usr '

-bash-3.00$ ./check_disk -w 10% -c 5% -v -p /usr
DISK CRITICAL - free space: /zones/k2proc/root/usr 8741023416033 MB (0% inode=-208431361588%);| /zones/k2proc/root/usr=-2147483648MB;-2147483648;-2147483648;0;-2147483648
-bash-3.00$

Dong a Truss on the check_disk command , it seem like statvfs64() is getting confused by the LOFS as Morven pointed out...

stat64("/usr", 0x08079878) = 0
sysconfig(_CONFIG_PAGESIZE) = 4096
stat64("/usr", 0x08079878) = 0
statvfs64("/zones/k2proc/root/usr", 0x08047B50) Err#13 EACCES [file_dac_search]
ioctl(1, TCGETA, 0x08046F74) = 0
fstat64(1, 0x08046EE0) = 0
DISK CRITICAL - free space: /zones/k2proc/root/usr 8741023416033 MB (0% inode=-208431361588%);| /zones/k2proc/root/usr=-2147483648MB;-2147483648;-2147483648;0;-2147483648
write(1, " D I S K C R I T I C A".., 171) = 171
_exit(2)
-bash-3.00$
---------------------------------------
However, if i check ' /usr/ ' (note: the trailing forward slash), it seem to work fine.

-bash-3.00$ ./check_disk -w 10% -c 5% -v -p /usr/
DISK OK - free space: /usr 3218 MB (80% inode=92%);| /usr=780MB;3636;3838;0;4040
-bash-3.00$

stat64("/usr/", 0x08079878) = 0
sysconfig(_CONFIG_PAGESIZE) = 4096
stat64("/usr/", 0x08079878) = 0
statvfs64("/usr", 0x08047B50) = 0
ioctl(1, TCGETA, 0x08046F74) = 0
fstat64(1, 0x08046EE0) = 0
DISK OK - free space: /usr 3218 MB (80% inode=92%);| /usr=780MB;3636;3838;0;4040
write(1, " D I S K O K - f r".., 81) = 81
_exit(0) 


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552849&group_id=29880