Xymon Mailing List Archive search

Ignoring file system when two "/" (root partitions) are reported

3 messages in this thread

list Bill Arlofski · Tue, 13 Sep 2011 13:45:17 -0400 ·
On a Gentoo Linux system, after a recent baselayout update to openrc 2.x (at
least I believe that to be the culprit) xymon clients are now reporting back
TWO  "/" (root) filesystems, and xymon v4.3.4 is reporting and graphing them
both like so:


Tue Sep 13 13:16:58 EDT 2011 - Filesystems NOT ok

(yellow) / (92% used) has reached the WARNING level (90%)
(yellow) / (92% used) has reached the WARNING level (90%)

Filesystem         1024-blocks      Used Available Capacity Mounted on
rootfs                96571704  88758608   7813096      92% /
/dev/root             96571704  88758608   7813096      92% /

In analyze.cfg I have tried to ignore rootfs and then the regular expression
versions just in case xymon matched the whole line reported, and not just the
info in the "Mounted on" column:

HOST=hostname.domain.tld
    DISK rootfs IGNORE

or

HOST=hostname.domain.tld
    DISK %rootfs IGNORE

or

HOST=hostname.domain.tld
    DISK %^rootfs IGNORE

or

HOST=hostname.domain.tld
    DISK /dev/root IGNORE


but these of course will not work since the docs for analyze.cfg say that the
DISK test works on the MOUNT POINT, not the device, or partition.

Is there any way to ignore ONE of the two disk reports that are essentially
the same exact thing, only reported in two different formats?


Also, as a side note/suggestion, the docs might be a bit ambiguous/confusing
with regards to "filesystem" and  "mount point", using them
semi-interchangeably which can be needlessly confusing:

#    DISK filesystem warnlevel paniclevel
#    DISK filesystem IGNORE
#   If the utilization of "filesystem" is reported to exceed "warnlevel"

Then filesystem is described as...
# "filesystem" is the mount-point where the filesystem is mounted, e.g.


Perhaps that could be more clear if the test was defined like so:

# DISK mountpoint warnlevel paniclevel
# DISK mountpoint IGNORE

Then, there would be no need for the "filesystem is the mount point..." line
since it would be self-evident

Thanks!

--
Bill Arlofski
Reverse Polarity, LLC
http://www.revpol.com/
list Bill Arlofski · Tue, 13 Sep 2011 15:39:14 -0400 ·
Hi Larry... Thanks for the reply (moving your reply to the list)

Sure I could, but this looks like something where I will not be the only one
affected, so I figured I'd report it and see if there was either

1. A correct way in analisys.cfg that I was just missing somehow

or

2. Have it 'fixed' in the default  (eg: in the release version) rather than me
making a one-off fix to some internal variables

Having said that, it looks like your solution will probably immediately fix my
problem and I will take a look at it as soon as I have a few minutes late
today or tomorrow.

Thanks

--
Bill Arlofski
Reverse Polarity, LLC
http://www.revpol.com/

On 09/13/11 14:40, Larry Barber wrote:
Could you insert a "grep -v rootfs" in the 'df' section of
xymonclient-linus.sh?

echo "[df]"
EXCLUDES=`cat /proc/filesystems | grep nodev | awk '{print $2}' | xargs echo
| sed -e 's! ! -x !g'`
df -Pl -x iso9660 -x $EXCLUDES | grep -v rootfs | sed -e '/^[^   ][^
]*$/{
N
s/[     ]*\n[   ]*/ /
}'

Thanks,
Larry Barber
quoted from Bill Arlofski

On Tue, Sep 13, 2011 at 12:45 PM, Bill Arlofski <user-0b8af203a56e@xymon.invalid>wrote:
On a Gentoo Linux system, after a recent baselayout update to openrc 2.x
(at
least I believe that to be the culprit) xymon clients are now reporting
back
TWO  "/" (root) filesystems, and xymon v4.3.4 is reporting and graphing
them
both like so:


Tue Sep 13 13:16:58 EDT 2011 - Filesystems NOT ok

(yellow) / (92% used) has reached the WARNING level (90%)
(yellow) / (92% used) has reached the WARNING level (90%)

Filesystem         1024-blocks      Used Available Capacity Mounted on
rootfs                96571704  88758608   7813096      92% /
/dev/root             96571704  88758608   7813096      92% /

In analyze.cfg I have tried to ignore rootfs and then the regular
expression
versions just in case xymon matched the whole line reported, and not just
the
info in the "Mounted on" column:

HOST=hostname.domain.tld
   DISK rootfs IGNORE

or

HOST=hostname.domain.tld
   DISK %rootfs IGNORE

or

HOST=hostname.domain.tld
   DISK %^rootfs IGNORE

or

HOST=hostname.domain.tld
   DISK /dev/root IGNORE


but these of course will not work since the docs for analyze.cfg say that
the
DISK test works on the MOUNT POINT, not the device, or partition.

Is there any way to ignore ONE of the two disk reports that are essentially
the same exact thing, only reported in two different formats?


Also, as a side note/suggestion, the docs might be a bit
ambiguous/confusing
with regards to "filesystem" and  "mount point", using them
semi-interchangeably which can be needlessly confusing:

#    DISK filesystem warnlevel paniclevel
#    DISK filesystem IGNORE
#   If the utilization of "filesystem" is reported to exceed "warnlevel"

Then filesystem is described as...
# "filesystem" is the mount-point where the filesystem is mounted, e.g.


Perhaps that could be more clear if the test was defined like so:

# DISK mountpoint warnlevel paniclevel
# DISK mountpoint IGNORE

Then, there would be no need for the "filesystem is the mount point..."
line
since it would be self-evident

Thanks!

--
Bill Arlofski
Reverse Polarity, LLC
http://www.revpol.com/

list Bill Arlofski · Wed, 14 Sep 2011 13:01:54 -0400 ·
quoted from Bill Arlofski
On 09/13/11 14:40, Larry Barber wrote:
Could you insert a "grep -v rootfs" in the 'df' section of
xymonclient-linus.sh?
Hi Larry... Just a follow-up:

This quick fix solution did work, however there are two things to consider here:

First, it needs to be done manually on every single client which reports the
rootfs and /dev/root devices.


And second, and even more important is that Interestingly enough, the
$EXCLUDES variable manually evaluates to include '-x rootfs'  so it should
ALREADY be excluded in the df command and the "grep -v rootfs" should not be
necessary.

See below:


When run manually the rootfs is not included in the output of the df command:

Get EXCLUDES:
$ cat /proc/filesystems | grep nodev | awk '{print $2}' | xargs echo \
| sed -e 's! ! -x !g'

returns: (on one line of course)
sysfs -x rootfs -x bdev -x proc -x tmpfs -x debugfs -x sockfs -x pipefs -x
anon_inodefs -x rpc_pipefs -x devpts -x ramfs -x hugetlbfs -x nfs -x nfsd -x
autofs -x mqueue -x vmblock


Notice that -x rootfs is in that list

so appending that list to the df command where the $EXCLUDES variable would be
evaluated like so:

df -Pl -x iso9660 -x sysfs -x rootfs -x bdev -x proc -x tmpfs -x debugfs -x
sockfs -x usbfs -x pipefs -x anon_inodefs -x rpc_pipefs -x devpts -x ramfs -x
hugetlbfs -x nfs -x nfs4 -x nfsd -x autofs

I get:

Filesystem         1024-blocks      Used Available Capacity Mounted on
/dev/root             30336296  20486696   8308568      72% /
/dev/hda1               241116     97737    130931      43% /boot
/dev/mapper/VolGroup0-Opt   5242716    698268   4544448      14% /opt
(and a few others that are properly reported but would wrap horribly here)


Where a straight forward df -Pl of course shows the rootfs filesystem:

$ df -Pl
Filesystem         1024-blocks      Used Available Capacity Mounted on
rootfs                30336296  20486884   8308380      72% /
/dev/root             30336296  20486884   8308380      72% /
rc-svcdir                 1024       136       888      14% /lib64/rc/init.d
udev                     10240       188     10052       2% /dev
shm                    2032040         0   2032040       0% /dev/shm
/dev/hda1               241116     97737    130931      43% /boot
/dev/mapper/VolGroup0-Opt   5242716    698268   4544448      14% /opt
(and a few others that are properly reported but would wrap horribly here)


Perhaps when the $EXCLUDES variable is evaluated by xymon, it does not propery
include the "-x rootfs" entry in the list, BUT the manual output listed above
is the same on two machines when run as any normal user or the xymon user so I
am not sure where the breakdown is...


--
Bill Arlofski
Reverse Polarity, LLC
http://www.revpol.com/