Minor bug found in xymonclient-linux.sh
I have been frustrated by the inclusion of tmpfs filesystems in xymon's client-side disk test. So I decided to see if I could fix the problem.
Running version 4.3.30.
In xymonclient-linux.sh, when defining the list of filesystem types to exclude, one of the commands it pipes through is this:
egrep -v 'tmpfs|rootfs|squashfs'
This grep removes tmpfs from the list of filesystems to exclude. So tmpfs filesystems are included. Changing the command to the following fixes the immediate problem that I have, but it should be reviewed for sanity by someone who's much more familiar with the code:
egrep -v 'rootfs|squashfs'
I actually came up with a command to define the excludes that's a little bit cleaner, but it required changes to more than just the one piped command. Let me know if you're interested in that.
Thanks, Shawn
On 24/07/2021 15:37, Shawn Heisey wrote:
I have been frustrated by the inclusion of tmpfs filesystems in xymon's client-side disk test.? So I decided to see if I could fix the problem.
Running version 4.3.30.
In xymonclient-linux.sh, when defining the list of filesystem types to exclude, one of the commands it pipes through is this:
egrep -v 'tmpfs|rootfs|squashfs'
This grep removes tmpfs from the list of filesystems to exclude.
I wouldn't call this a bug; there are use cases for wanting to monitor tmpfs filesystems. See e.g.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=487157
which I realise is quite old but might well still be relevant, and I could imagine other more up-to-date situations. /run is tmpfs, and a full /run would likely cause problems for example.
Instead, I think you might look at your analysis.cfg on your xymon server. If you want to ignore the reported data for /run on all of your systems, you can add to the DEFAULT section of your analysis.cfg:
DEFAULT
whatever DEFAULT rules are already there
DISK /run IGNORE
or you could more selectively ignore /run (or whatever mountpoints you're not interested in) for HOSTs, PAGEs etc as described in "man analysis.cfg"
Regards,
Adam
On Mon, 2021-07-26 at 18:26 +0100, Adam Thorn wrote:
On 24/07/2021 15:37, Shawn Heisey wrote:
I have been frustrated by the inclusion of tmpfs filesystems in xymon's client-side disk test. So I decided to see if I could fix the problem.
Running version 4.3.30.
In xymonclient-linux.sh, when defining the list of filesystem types to exclude, one of the commands it pipes through is this:
egrep -v 'tmpfs|rootfs|squashfs'
This grep removes tmpfs from the list of filesystems to exclude.
I wouldn't call this a bug; there are use cases for wanting to monitor tmpfs filesystems. See e.g.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=487157
which I realise is quite old but might well still be relevant, and I could imagine other more up-to-date situations. /run is tmpfs, and a full /run would likely cause problems for example.
Instead, I think you might look at your analysis.cfg on your xymon server. If you want to ignore the reported data for /run on all of your systems, you can add to the DEFAULT section of your analysis.cfg:
DEFAULT
whatever DEFAULT rules are already there
DISK /run IGNORE
I would add that I also ignore the inode check for such filesystems (it avoids them appearing in the inode test graphs):
INODE /run IGNORE
John.
-- John Horne | Senior Operations Analyst | Technology and Information Services University of Plymouth | Drake Circus | Plymouth | Devon | PL4 8AA | UK
[http://www.plymouth.ac.uk/images/email_footer.gif]<http://www.plymouth.ac.uk/worldclass>
This email and any files with it are confidential and intended solely for the use of the recipient to whom it is addressed. If you are not the intended recipient then copying, distribution or other use of the information contained is strictly prohibited and you should not rely on it. If you have received this email in error please let the sender know immediately and delete it from your system(s). Internet emails are not necessarily secure. While we take every care, University of Plymouth accepts no responsibility for viruses and it is your responsibility to scan emails and their attachments. University of Plymouth does not accept responsibility for any changes made after it was sent. Nothing in this email or its attachments constitutes an order for goods or services unless accompanied by an official order form.
participants (3)
-
alt36＠cam.ac.uk
-
hobbit＠elyograg.org
-
john.horne＠plymouth.ac.uk