- Xymon - Xymon mailman web

graph interval selector breaks for non-standard width graphs
by dboldt＠usgs.gov 19 Nov '19

19 Nov '19

With graph width doubled via option "-w 1152", the web based tool which uses a crosshair to select a subset of the displayed graph no longer works correctly. Perhaps showgraph.sh does not know the true size of the graph?

1 0

semop failed, Invalid argument
by john.horne＠plymouth.ac.uk 12 Nov '19

12 Nov '19

On Tue, 2019-11-12 at 17:03 +0000, Rothlisberger, John R. via Xymon wrote: > > Does anyone have any helpful ideas? > ... > > 2019-11-01 11:45:07.083973 semop failed, Invalid argument > 2019-11-01 11:45:07.083982 Dropping message due to semaphore error > Not really I'm afraid. The actual error is the invalid argument bit. It refers to a call to 'semop'. A very quick look at the xymond code seems to indicate that it would be the semaphore id that it is objecting to - basically it doesn't exist or the id is less than zero. How that came about though, I have no idea. It may be that the code is being called when it shouldn't be - perhaps a lack of argument checking. It would require much further checking of the code to see what is happening. Maybe running xymond is debug mode will give more information. 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.

1 0

semop failed, Invalid argument
by john.r.rothlisberger＠accenture.com 12 Nov '19

12 Nov '19

I have been battling this semop failed message for a couple of months on multiple servers. On some servers it is only occasionally, on this particular server it is happened over 90 times in a single day (on multiple occasions). Then, there are days it runs fine. I have upgraded to 4.3.30 on this particular server though it has happened using 4.3.21 & 4.3.28. Reboots do not solve it. It is so bad that I have a cron script running every 10 minutes looking for the errors in the xymod.log file and restarting Xymon automatically. Xymond.log: 2019-11-01 11:33:12.197864 Setup complete 2019-11-01 11:45:07.029630 semop failed, Invalid argument 2019-11-01 11:45:07.029669 Dropping message due to semaphore error 2019-11-01 11:45:07.083973 semop failed, Invalid argument 2019-11-01 11:45:07.083982 Dropping message due to semaphore error .... <hundreds to thousands of these messages> Ubuntu 16.04LTS Xymon 4.3.30 Thanks, John Upcoming PTO: _____________________________________________________________________ John Rothlisberger IT Strategy, Infrastructure & Security - Technology Growth Platform TGP for Business Process Outsourcing Accenture 312.693.3136 office _____________________________________________________________________ ________________________________ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. Your privacy is important to us. Accenture uses your personal data only in compliance with data protection laws. For further information on how Accenture processes your personal data, please see our privacy statement at https://www.accenture.com/us-en/privacy-policy. ______________________________________________________________________________________ www.accenture.com

1 1

diskstat.pl
by christian.becker＠rhein-zeitung.net 12 Nov '19

12 Nov '19

I forgot to include the following code snippet from Wim Nelis? script diskstat.pl ? no idea if something has to be adjusted here. This is where he describes and initializes the DS types: # Define the name of each data-set, the unit conversion factor and the RRD type. # Note that RRD requires that the values of type 'DERIVE' are integer. If # however floating point numbers are used, the RRD type must be set to # 'DDERIVE'. # my @DS= ( # Define parameters of the datasets [ 'Name' , 1, '' ], # 0 - Name of disk / partition [ 'RdRequest', 1, 'DERIVE' ], # 1 - Read requests [ 'RdMerge' , 1, 'DERIVE' ], # 2 - Read request merges [ 'RdAmount' , 512, 'DERIVE' ], # 3 - Sectors read [ 'RdTime' , 0.001, 'DDERIVE' ], # 4 - Time spent reading [ms] [ 'WrRequest', 1, 'DERIVE' ], # 5 - Write requests [ 'WrMerge' , 1, 'DERIVE' ], # 6 - Write request merges [ 'WrAmount' , 512, 'DERIVE' ], # 7 - Sectors written [ 'WrTime' , 0.001, 'DDERIVE' ], # 8 - Time spent writing [ms] [ 'IoQueue' , 1, 'GAUGE' ], # 9 - Length of I/O queue [ 'IoTime' , 0.001, 'DDERIVE' ], # 10 - Time spent for I/O [ms] [ 'IoWTime' , 0.001, 'DDERIVE' ] # 11 - Time weighted with (9) ) ; Regards Christian Von: SebA <spah at syntec.co.uk> Gesendet: Dienstag, 12. November 2019 12:26 An: Becker Christian <christian.becker at rhein-zeitung.net> Betreff: Re: [Xymon] diskstat.pl I believe that error is coming out of rrdtool, not perl. Kind regards, SebA On Tue, 12 Nov 2019, 10:41 am Becker Christian, <christian.becker at rhein-zeitung.net<mailto:christian.becker at rhein-zeitung.net>> wrote: Hello together, following wiki.xymonton.org<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwiki.xymon…>, i found Wim Nelis? entry diskstat.pl<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdiskstat.p…> which I already successfully used nearly 4 years ago. Unfortunately I have migrated our xymon server since then, in addition to that the ?old? linux machine on which diskstat.pl<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdiskstat.p…> was initially used doesn?t exist any longer. Now I wanted to use diskstat.pl<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdiskstat.p…> again on a new linux client, and therefore I looked to the entry at wiki.xymonton.org<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwiki.xymon…> again, but I found a newer version of diskstat.pl<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdiskstat.p…> (now using devmon format). I followed all the steps, but my result is an entry on the xymon server in the logfile rrd-status.log: 2019-10-18 11:44:07.817334 RRD error creating /opt/xymon/data/rrd/linuxclient1/diskstat.,root.rrd: invalid DS type specified 2019-10-18 11:44:07.817620 RRD error creating /opt/xymon/data/rrd/linuxclient1/diskstat.,var.rrd: invalid DS type specified 2019-10-18 11:44:07.817660 RRD error creating /opt/xymon/data/rrd/linuxclient1/diskstat.,opt.rrd: invalid DS type specified 2019-10-18 11:44:07.817704 RRD error creating /opt/xymon/data/rrd/linuxclient1/diskstat.,boot.rrd: invalid DS type specified The diskstat.pm<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdiskstat.p…> on linuxclient1 looks as follows: sh-4.1$ cat diskstat.pm<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdiskstat.p…> package diskstat ; # # Specify the disks and partitions to be monitored, and the name of the # associated mount-point. The latter is shown in the resulting graph. # require Exporter ; our @ISA = qw/ Exporter / ; our @EXPORT= qw/ %Disks / ; %Disks= ( "sda1" => { Name => "/boot" }, "dm-1" => { Name => "/" }, "dm-6" => { Name => "/var" }, "dm-7" => { Name => "/opt" }, ) ; 1 ; My perl isn?t good enough to find out why it says invalid DS type specified. Do you have any suggestions what could have went wrong here?? My xymon client (linuxclient1) is running CentOS 6.6 64 Bit, my xymon server is running CentOS 7.7 64 Bit. Do you need more information? Best regards from Germany Christian _______________________________________________ Xymon mailing list Xymon at xymon.com<mailto:Xymon at xymon.com> http://lists.xymon.com/mailman/listinfo/xymon<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.xymo…>

2 1

diskstat.pl
by christian.becker＠rhein-zeitung.net 12 Nov '19

12 Nov '19

Hello together, following wiki.xymonton.org, i found Wim Nelis' entry diskstat.pl which I already successfully used nearly 4 years ago. Unfortunately I have migrated our xymon server since then, in addition to that the "old" linux machine on which diskstat.pl was initially used doesn't exist any longer. Now I wanted to use diskstat.pl again on a new linux client, and therefore I looked to the entry at wiki.xymonton.org again, but I found a newer version of diskstat.pl (now using devmon format). I followed all the steps, but my result is an entry on the xymon server in the logfile rrd-status.log: 2019-10-18 11:44:07.817334 RRD error creating /opt/xymon/data/rrd/linuxclient1/diskstat.,root.rrd: invalid DS type specified 2019-10-18 11:44:07.817620 RRD error creating /opt/xymon/data/rrd/linuxclient1/diskstat.,var.rrd: invalid DS type specified 2019-10-18 11:44:07.817660 RRD error creating /opt/xymon/data/rrd/linuxclient1/diskstat.,opt.rrd: invalid DS type specified 2019-10-18 11:44:07.817704 RRD error creating /opt/xymon/data/rrd/linuxclient1/diskstat.,boot.rrd: invalid DS type specified The diskstat.pm on linuxclient1 looks as follows: sh-4.1$ cat diskstat.pm package diskstat ; # # Specify the disks and partitions to be monitored, and the name of the # associated mount-point. The latter is shown in the resulting graph. # require Exporter ; our @ISA = qw/ Exporter / ; our @EXPORT= qw/ %Disks / ; %Disks= ( "sda1" => { Name => "/boot" }, "dm-1" => { Name => "/" }, "dm-6" => { Name => "/var" }, "dm-7" => { Name => "/opt" }, ) ; 1 ; My perl isn't good enough to find out why it says invalid DS type specified. Do you have any suggestions what could have went wrong here?? My xymon client (linuxclient1) is running CentOS 6.6 64 Bit, my xymon server is running CentOS 7.7 64 Bit. Do you need more information? Best regards from Germany Christian

1 0

IGNORE in alerts.cfg
by Paul.Root＠CenturyLink.com 11 Nov '19

11 Nov '19

I'm having an issue with an IGNORE statement. Is the time put in relative to the client machine or the server? My server is in central time, but the client machine is mountain time. Though I set TZ in my environment, the xymon user does not. It is looking like it is relative to client. I have IGNORE SERVICE=procs,ports TIME=0:1715:1815 For a restart. But just got paged again. Sun Nov 10 17:44:59 2019 nsmdenvp185 http nl-tcnms Paul Root Lead Operations Engineer - IT Managed Services 390 Commerce Dr Woodbury, Mn 55125 651-312-5207 paul.root at centurylink.com This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.

1 0

off-by-one bug in analysis.cfg "FILE ... SIZE>x" checks
by abe＠deuxchevaux.org 08 Nov '19

08 Nov '19

Hi, it just took me an hour or two to realize why I had false negatives (i.e. missing alerts) on empty files:

1 0

Source of "Xymon [hostname]:[service] recovered? (stale)" alerts
by earle＠isolar.DynDNS.ORG 06 Nov '19

06 Nov '19

All: Ever since I upgraded my work setup from Xymon 4.3.12 to 4.3.28 (on RHEL 7.6), I've been seeing situations where we'll get alerts that should be one-time only (or maybe twice), but they stick around persistently. We keep getting the same alert every hour until someone restarts the Xymon service. Once the service is restarted, the alert goes away and we get a "Xymon [hostname]:[service] recovered? (stale)" alert in its place. The frequency of them seems to be somewhat random. Some days I don't get any. Then 3 days ago I had 6 instances of them, 2 days ago there were only 2, then 5 more yesterday. They are usually "msgs" service alerts, but not all the time. I've seen some for "conn" or "cpu", and even one for a "telnet" check we have for an APC UPS. What really surprised me is that in my 5 1/2+ years of archives of this mailing list, I don't see any mentions of this issue. I could toss in a "cron" job to automatically restart Xymon once a day, but that's a kludge. What could be possible causes of these 'stuck'/repeated alerts, which end up becoming stale? I noticed that alerts.cfg(5) says > (A stale alert is one where the service recovered during a +time that > xymond_alert was not running.) but that doesn't seem to be applicable here - unless it's describing the brief period between stopping & restarting the Xymon service. - Greg

1 0

[PATCH] - client data link on graphs
by john.horne＠plymouth.ac.uk 24 Oct '19

24 Oct '19

Hello, We are using the Terabithia 4.3.30 RPMs. For most of the test web pages, a link to the data sent by the client is shown on the page. This is seen in the 'Client data available' message on the page. This is something we do not want. The graphs can be seen by our users, but we do not want details of the clients (servers) being made available. (We have previously just commented out the relevant bit of code, but this requires rebuilding the RPMs at each release.) This patch simply provides a 'xymonserver.cfg' variable ('SHOWCLIENTLINK') which be can set to true or false. The default value is true, which will cause the link to be displayed (as before). The patches are all very small, typically just one or two lines. The patches do not affect the collecting of the client data in any way. Instead, just before the link would be displayed, a simple check of the variable is performed to see if the link should be displayed or not. Note - it was noticed that the html pages and man pages included the 'CLIENTSVCS' xymonserver.cfg variable. However, looking at the source code, this variable is not used anywhere. It should be removed from the documentation. 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.

1 0

[PATCH] - xymonserver - all ok message - part 2
by john.horne＠plymouth.ac.uk 24 Oct '19

24 Oct '19

Hello, This is the second of two sets of patches, both of which are based on the Terabithia 4.3.30 RPMs. Currently when all the clients/hosts report green a message on the 'All non- green view' page is displayed saying 'All Monitored Systems OK'. I was asked 'what' is all green - that is, how many things are you testing? These patches allow the above message to include two variables which will be converted into numbers. (Management love to see numbers.) One variable (#XMHOSTS) reports the number of clients/hosts configured (taken from the xymongen.c 'hostcount' variable), the second variable (#XMTESTS) shows the number of tests being performed (taken from the xymongen.c 'statuscount' variable). So, in our case we have the following defined in our xymonserver.cfg file: ====== XYMONALLOKTEXT=" All Monitored Systems OK (Monitoring #XMHOSTS devices;  performing #XMTESTS tests) " ====== So when everything is green, then on the 'All non-green view' web page we see the following message (centered on the page): ===== All Monitored Systems OK (Monitoring 62 devices; performing 1165 tests) ===== The first set of patches created a second xymonserver.cfg configuration variable (XYMONALLOKCRIT) to be used on the 'Critical systems' web page. The reason was that the number of clients/hosts and tests may be misinterpreted if displayed on that page. For example, is the number of hosts the total number of hosts or just the number of configured critical hosts? To avoid any misinterpretation, XYMONALLOKCRIT does not expand any included variables. Included in these patches is a change to the 'loaddata.c' file. This produces the statistics shown on the xymongen web page. It excludes the count of 'info' and 'trends' messages, since these are generated by Xymon and not real tests. By default they always show a green colour, although the colour is configurable in the xymonserver.cfg file, and so would bias the green percentage. The patch excludes the 'clientlog' entries as well. These too are always shown as green by default. Although they are not generated as such, the column just shows data already received from the client. As such they are not an actual test, and should not be included in the statistics. By doing this, the 'statuscount' value now matches the number of actual test results seen in the '/var/lib/xymon/hist' directory. Again, the patches are relatively small in size. 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.

2 4