[ZBXNEXT-1772] Use /proc/self/mountinfo for filesystem discovery in Linux >= 2.6.26 Created: 2013 May 31  Updated: 2016 Oct 12

Status: Open
Project: ZABBIX FEATURE REQUESTS
Component/s: Agent (G)
Affects Version/s: 2.0.6, 2.1.1
Fix Version/s: None

Type: Change Request Priority: Minor
Reporter: Volker Fröhlich Assignee: Unassigned
Resolution: Unresolved Votes: 14
Labels: bind, lld
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux



 Description   

/proc/mounts allows no distinction between regular mounts and bind mounts. That leads to having the same filesystem discovered multiple times. On some platforms this can potentially be worked around by parsing /etc/mtab, but that's not as reliable, as it does not represent the kernel's view.

Bind mounts were introduced in Linux 2.4.0 (man 2 mount). /proc/self/mountinfo was introduced in 2.6.26 to solve the problem of not being able to recognize bind mounts. Please also refer to this discussion: https://bugzilla.redhat.com/show_bug.cgi?id=491924, particularly comment #20.

The findmnt utility might bring some inspiration for how using different sources of information, including mountinfo, can be implemented.
http://man7.org/linux/man-pages//man8/findmnt.8.html



 Comments   
Comment by Oleksii Zagorskyi [ 2013 Jun 01 ]

Looks like related to ZBX-5676

Comment by Dmitry Verkhoturov [ 2015 Sep 15 ]

Could someone please review that one? Discovering bind mounts adding a mess in big infrastructure, it's really easy to fix this one.

Comment by Dmitry Verkhoturov [ 2015 Dec 07 ]

Workaround (linux only):

$ cat /etc/zabbix/conf.d/mountstate.conf
# vfs.fs.discovery_except_bind takes /etc/mtab, filters lines with bind in mount options and "none" mount device, and prints as json for zabbix low level discovery
UserParameter=vfs.fs.discovery_except_bind,x=`awk '$1 !~/none/ && $4 !~/bind/ {print "{\"{#FSNAME}\":\"" $2 "\",\"{#FSTYPE}\":\"" $3 "\"},"}' /etc/mtab | sed -e '$s/.$//'` ; echo "{\"data\":[${x}]}"
Generated at Wed May 07 06:12:37 EEST 2025 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.