[ZBXNEXT-5490] Zabbix agent returns incorrect data for unmounted file systems Created: 2019 Sep 17  Updated: 2024 Apr 10  Resolved: 2020 Mar 29

Status: Closed
Project: ZABBIX FEATURE REQUESTS
Component/s: Agent (G)
Affects Version/s: 4.0.12, 4.2.6
Fix Version/s: 4.0.17rc1, 4.4.5rc1, 5.0.0alpha1, 5.0 (plan)

Type: New Feature Request Priority: Major
Reporter: DaneT Assignee: Andrejs Kozlovs
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File ZBXNEXT-5490-4_0_patch.tar.gz    
Issue Links:
Causes
causes ZBX-17505 Crash inside a fork when calling vfs.... Closed
Duplicate
Sub-task
depends on ZBX-16459 Escaping backslash in jsonpath using ... Closed
Team: Team C
Sprint: Sprint 57 (Oct 2019), Sprint 58 (Nov 2019), Sprint 59 (Dec 2019), Sprint 60 (Jan 2020), Sprint 62 (Mar 2020)
Story Points: 5

 Description   

We have two servers, active-pasive, sharing a file system, which is only mounted in the active node.

When server A have that FS mounted, it is reported to zabbix, via LLD, and data recolected.

ACHIEVED RESULT:
If that FS is umounted, the item "vfs.fs.size" returns the data from FS where that path exists ("/" in our case).

In Linux we see that info is recovered from statvfs, which produces that behaviour.

EXPECTED RESULT:
vfs.fs.size does not return any value if the path is not a mount point

This behaviour is observed with all Zabbix versions

Agent requests:

# zabbix_get -s hpuxnode -k "vfs.fs.size[/,pused]"
3.575193
# zabbix_get -s hpuxnode -k "vfs.fs.size[/etc,pused]"
3.575193
# zabbix_get -s hpuxnode -k "vfs.fs.size[/etc/hosts,pused]"
3.575193

Mount points:

/ on /dev/vg00/lvol3 ioerror=mwdisable,largefiles,delaylog,dev=80002003 on Fri Mar  1 10:21:10 2019
/stand on /dev/vg00/lvol1 ioerror=mwdisable,nolargefiles,log,tranflush,dev=80002001 on Fri Mar  1 10:21:17 2019
/var on /dev/vg00/lvol8 ioerror=mwdisable,largefiles,delaylog,dev=80002008 on Fri Mar  1 10:21:30 2019
/usr on /dev/vg00/lvol7 ioerror=mwdisable,largefiles,delaylog,dev=80002007 on Fri Mar  1 10:21:30 2019
/tmp on /dev/vg00/lvol6 ioerror=mwdisable,largefiles,delaylog,dev=80002006 on Fri Mar  1 10:21:30 2019
/opt on /dev/vg00/lvol5 ioerror=mwdisable,largefiles,delaylog,dev=80002005 on Fri Mar  1 10:21:30 2019
/home on /dev/vg00/lvol4 ioerror=mwdisable,largefiles,delaylog,dev=80002004 on Fri Mar  1 10:21:31 2019


 Comments   
Comment by DaneT [ 2019 Sep 17 ]

Additional information on the checking unmounted filesystems:
http://man7.org/linux/man-pages/man3/getmntent.3.html

output on Centos 7 with Zabbix 4.0.12:

[root@student-03 ~]# lsblk
NAME            MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda               8:0    0     8G  0 disk
├─sda1            8:1    0     1G  0 part /boot
└─sda2            8:2    0     7G  0 part
  ├─centos-root 253:0    0   6.2G  0 lvm  /
  └─centos-swap 253:1    0   820M  0 lvm  [SWAP]
sdb               8:16   0 104.4M  0 disk
├─sdb1            8:17   0    95M  0 part
└─sdb9            8:25   0     8M  0 part
sdc               8:32   0 104.4M  0 disk
├─sdc1            8:33   0    95M  0 part
└─sdc9            8:41   0     8M  0 part
sr0              11:0    1  1024M  0 rom
[root@student-03 ~]# zabbix_get -s 127.0.0.1 -k "vfs.fs.size[/dev/sdb,pused]"
0.000000
[root@student-03 ~]#
Comment by Adrian Lopez [ 2019 Oct 01 ]

Workaround for AIX, returning a ZBX_NOTSUPPORTED error if the path is not a mountpoint:

 

Alias=vfs.fs.size:mounted.vfs.fs.size
Alias=vfs.fs.inode:mounted.vfs.fs.inode
Alias=orig.vfs.fs.size[*]:vfs.fs.size[*]
Alias=orig.vfs.fs.inode[*]:vfs.fs.inode[*]
UserParameter=mounted.vfs.fs.size[*],mount | grep " $1 " >& /dev/null && /opt/freeware/bin/zabbix_get -s 127.0.0.1 -k "vfs.fs.size[$1,$2]" || echo "ZBX_NOTSUPPORTED: Cannot obtain filesystem information: No such mountpoint"
UserParameter=mounted.vfs.fs.inode[*],mount | grep " $1 " >& /dev/null && /opt/freeware/bin/zabbix_get -s 127.0.0.1 -k "vfs.fs.inode[$1,$2]" || echo "ZBX_NOTSUPPORTED: Cannot obtain filesystem information: No such mountpoint"

 

 

 

For HP-UX:

UserParameter=mounted.vfs.fs.size[*],mount | grep "^$1 " >& /dev/null && /usr/bin/zabbix_get -s 127.0.0.1 -k "vfs.fs.size[$1,$2]" || echo "ZBX_NOTSUPPORTED: Cannot obtain filesystem information: No such mountpoint"
UserParameter=mounted.vfs.fs.inode[*],mount | grep "^$1 " >& /dev/null && /usr/bin/zabbix_get -s 127.0.0.1 -k "vfs.fs.inode[$1,$2]" || echo "ZBX_NOTSUPPORTED: Cannot obtain filesystem information: No such mountpoint"
Comment by Vladislavs Sokurenko [ 2019 Oct 08 ]

LLD can be used to determine no longer discovered items and remove them if they are unmounted, can this be sufficient ?

Comment by Adrian Lopez [ 2019 Oct 08 ]

LLD is executed with longer periods than recollection of metrics.

Once one disk is unmounted, the next metric is going to report the value incorrectly, possibly triggering an alarm.
In fact that is our case, network FS being unmounted generating an alarm because "/" is quite full.

Comment by Vladislavs Sokurenko [ 2019 Oct 08 ]

It currently works as documented

In case of a mounted volume, disk space for local file system is returned.

Do you think that changing existing behaviour could cause trouble on existing installations?

Comment by Vladislavs Sokurenko [ 2019 Oct 08 ]

Description of currently used function statvfs():

The function statvfs() returns information about a mounted file system. path is the pathname of any file within the mounted file system.

Comment by Adrian Lopez [ 2019 Oct 14 ]

My idea of how to solve this issue is to only accept a valid mount point for the first parameter.
Other path should return a ZBX_NOTSUPPORTED error.

Using this solution I could imagine a corner case where it could break. If some user has manually defined "vfs.fs.size[/etc,free]" for all servers and some of them does not have a mount point for /etc, that item will become unsupported, while with the current implementation, it will return the free of mount point "/".

But I suppose most users use the disk discovery rule to monitor mount points, so it is more probably that a lot of users are getting incorrect data of unmounted volumes.

Comment by Andrejs Kozlovs [ 2020 Jan 14 ]

Fixed in:

Comment by Yuuki Enomoto [ 2020 Jan 15 ]

HPUX build was failed in my environment at 4779228caf0.

 

diskspace.c: In function 'vfs_fs_get':
diskspace.c:268: error: 'zmt' undeclared (first use in this function)
diskspace.c:268: error: (Each undeclared identifier is reported only once
diskspace.c:268: error: for each function it appears in.)

I think this is solution.

 

 

--- a/src/libs/zbxsysinfo/hpux/diskspace.c
+++ b/src/libs/zbxsysinfo/hpux/diskspace.c
@@ -265,7 +265,7 @@ static int  vfs_fs_get(AGENT_REQUEST *request, AGENT_RESULT *result)
                }
                mntpoint = (zbx_mpoint_t *)zbx_malloc(NULL, sizeof(zbx_mpoint_t));
                zbx_strlcpy(mntpoint->fsname, mpoint, MAX_STRING_LEN);
-               zbx_strlcpy(mntpoint->fstype, zmt->mnt_type, MAX_STRING_LEN);
+               zbx_strlcpy(mntpoint->fstype, mt->mnt_type, MAX_STRING_LEN);
                mntpoint->total = total;
                mntpoint->used = used;
                mntpoint->not_used = not_used;

 

 

Comment by Alexander Vladishev [ 2020 Feb 01 ]

Updated documentation:

Generated at Mon Mar 17 05:13:28 EET 2025 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.