- Xymon - Xymon mailman web

Xymon 4.3.13 is out
by henrik＠hswn.dk 08 Jan '14

08 Jan '14

Version 4.3.13 landed on Sourceforge a few minutes ago, marking the beginning of the new year. You can grab it at http://sourceforge.net/projects/xymon/files/latest/download Preparations for a release of version 5 is underway, the current code is now running at http://beta.xymon.com/ Regards, Henrik

8 10

BUG REPORT: double utc correction on windows powershell client
by glauber.ribeiro＠experian.com 08 Jan '14

08 Jan '14

(I reported this yesterday. Just cleaning up and changing the subject to make it a bug report.) In the Powershell client: Function epochTime assumes a local time and converts it to UTC: function epochTime([System.DateTime] $t) { [uint32](($t.Ticks - ([DateTime] "1/1/1970 00:00:00").Ticks) / 10000000) - $osinfo.CurrentTimeZone*60 } But it's being used on times that are already UTC function XymonFileStat($file,$hash="") { ... "atime:{0} ({1})" -f (epochTime $fh.LastAccessTimeUtc),$fh.LastAccessTime.ToString("yyyy/MM/dd-HH:mm:ss") "ctime:{0} ({1})" -f (epochTime $fh.CreationTimeUtc),$fh.CreationTime.ToString("yyyy/MM/dd-HH:mm:ss") "mtime:{0} ({1})" -f (epochTime $fh.LastWriteTimeUtc),$fh.LastWriteTime.ToString("yyyy/MM/dd-HH:mm:ss") ... } I think the fix is to change the lines above to "atime:{0} ({1})" -f (epochTime $fh.LastAccessTime),$fh.LastAccessTime.ToString("yyyy/MM/dd-HH:mm:ss") "ctime:{0} ({1})" -f (epochTime $fh.CreationTime),$fh.CreationTime.ToString("yyyy/MM/dd-HH:mm:ss") "mtime:{0} ({1})" -f (epochTime $fh.LastWriteTime),$fh.LastWriteTime.ToString("yyyy/MM/dd-HH:mm:ss") glauber

1 0

Possible xymon bug - use of RRDPARAM in custom graphs
by ozkrumpet＠gmail.com 08 Jan '14

08 Jan '14

Hi everyone, I think I may have identified a possible bug in xymon. I am currently running 4.3.12. I am attempting to define a custom graph using the RRDPARAM variable to define the graph. The data that is "supplying" the graph is being generated by a custom check and it stores this data over several rrd files with a single value in each file. They key line in my graph definition is: DEF:p at RRDIDX@=@RRDFN@:@RRDPARAM@:AVERAGE What appears to be happening is that the different variables names that represent the different parameters for the graph are different lengths. It seems that what ends up being supplied to rdd on this line in the graph definition contains extra white space added into the @RRDPARAM@ part of the definition line and that these extra whitespaces correspond to the largest variable name length. It seems to me that the internal data structure is getting sized to the largest string length and then not reduced for subsequent smaller strings and it just pads the rest with whitespace. RRD then gets confused as it is looking for a variable named "variable1 ", while the rrd file actually contains a variable called "variable1". I would love to get the bug fixed as it is preventing some of my graphs working. Happy to also be told there is a better way to do this. I hope this makes sense. Happy to provide more info if required. Alex

2 2

Critical Alert Log always green
by hastymind＠googlemail.com 08 Jan '14

08 Jan '14

Hi, I have had this problem since 4.3.4 (when it was the --nklog option for BBGENOPTS) and not had chance to track it down. In my site, the column and the log are always green despite the critical view showing plenty of red. Have just implemented 4.3.12 and find the same is still happening, but this is on a non-production test environment with only 1 server monitored so I am pretty sure I can rule out legacy data or misconfiguration. So, does anyone else see this or can anyone point to an area of configuration I have missed? What I have is :- XYMONGENOPTS="--recentgifs --subpagecolumns=2 --criticallog" and I get the critical column and the criticalstatus.log that I expected but they do not record what I was hoping for. Will continue faking this with curl unless someone has any suggestions? Thanks -- Andy

2 1

adding --hffile back to criticalview
by abs＠shadymint.com 08 Jan '14

08 Jan '14

Hi, Any chance we could have this patch added please, it restores the --hffile option so I can have customised headers and footers for my various critical views.. *** web/criticalview.c.FCS 2012-07-14 17:32:11.000000000 +0100 --- web/criticalview.c 2014-01-05 19:36:19.000000000 +0000 *************** *** 445,450 **** --- 445,451 ---- int argi; char *envarea = NULL; char **critconfig = NULL; + char *hffile = "critical"; int cccount = 0; critconfig = (char **)calloc(1, sizeof(char *)); *************** *** 476,481 **** --- 477,486 ---- critconfig = (char **)realloc(critconfig, (1 + cccount)*sizeof(char *)); critconfig[cccount] = NULL; } + else if (argnmatch(argv[argi], "--hffile=")) { + char *p = strchr(argv[argi], '='); + hffile = strdup(p+1); + } } if (!critconfig[0]) { *************** *** 546,553 **** } generate_critpage(rbstate[i], hostsonpage[i], stdout, ! (i == 0) ? (critconfig[1] ? "critmulti" : "critical") : "divider", ! (critconfig[i+1] == NULL) ? "critical" : "divider", partcolor[i], partprio[i]); } } --- 551,558 ---- } generate_critpage(rbstate[i], hostsonpage[i], stdout, ! (i == 0) ? (critconfig[1] ? "critmulti" : hffile) : "divider", ! (critconfig[i+1] == NULL) ? hffile : "divider", partcolor[i], partprio[i]); } } Thanks -- Andy

2 1

Is the powershell windows client reporting file time incorrectly?
by glauber.ribeiro＠experian.com 07 Jan '14

07 Jan '14

It looks as if in the new client, the GMT correction is being applied twice, or GMT correction is being applied to a time that's already in GMT. g -----Original Message----- From: Ribeiro, Glauber Sent: Tuesday, January 07, 2014 16:02 To: 'xymon at xymon.com' Subject: Is the powershell windows client reporting file time incorrectly? Please see this: http://lists.xymon.com/oldarchive/2008/06/msg00441.html And here is what the new client reports for a file in my system: [file:D:\tsiback\today\tsbackup.log] type:100000 (file) mode:777 (not implemented) linkcount:1 owner:0 (BUILTIN\Administrators) group:0 (MCKOEMTAB3\None) size:7764 atime:1389100219 (2014/01/07-01:10:18) ctime:1389100219 (2014/01/07-01:10:18) mtime:1389100676 (2014/01/07-01:17:56) FileVersion: FileDescription: Let's take mtime. 2014/01/07-01:17:56 is correct, in local time. 1389100676, if I'm not mistaken (big if) is 2014-01-07 13:17:56 I'm at GMT-6 (USA Central Time), so the correct time stamp for the file in GMT would have been 07:17, not 13:17. Xymon sees the time "in the future" and reports that the file is massively out of synch ("File was modified 4294959253 seconds ago - should be <108000"). ================================== Compare with the old BBWin client (same file name, but different server): [file:d:/tsiback/today/tsbackup.log] type:0x00020 (file) mode:777 (not implemented) linkcount:1 owner:0 (not implemented) group:0 (not implemented) size:4823 atime:1389062375 (2014/01/7-02:39:35) ctime:1389058500 (2014/01/7-01:35:00) mtime:1389062373 (2014/01/7-02:39:33) 1389062373 is 2014-01-07 02:39:33, so the old client is reporting the unixepoch in local time, as described in the old bug report I mentioned at the start of this email. Also, why is the "type" reported differently? (100000 versus 0x0020) Does it matter? glauber

1 0

Is the powershell windows client reporting file time incorrectly?
by glauber.ribeiro＠experian.com 07 Jan '14

07 Jan '14

Please see this: http://lists.xymon.com/oldarchive/2008/06/msg00441.html And here is what the new client reports for a file in my system: [file:D:\tsiback\today\tsbackup.log] type:100000 (file) mode:777 (not implemented) linkcount:1 owner:0 (BUILTIN\Administrators) group:0 (MCKOEMTAB3\None) size:7764 atime:1389100219 (2014/01/07-01:10:18) ctime:1389100219 (2014/01/07-01:10:18) mtime:1389100676 (2014/01/07-01:17:56) FileVersion: FileDescription: Let's take mtime. 2014/01/07-01:17:56 is correct, in local time. 1389100676, if I'm not mistaken (big if) is 2014-01-07 13:17:56 I'm at GMT-6 (USA Central Time), so the correct time stamp for the file in GMT would have been 07:17, not 13:17. Xymon sees the time "in the future" and reports that the file is massively out of synch ("File was modified 4294959253 seconds ago - should be <108000"). ================================== Compare with the old BBWin client (same file name, but different server): [file:d:/tsiback/today/tsbackup.log] type:0x00020 (file) mode:777 (not implemented) linkcount:1 owner:0 (not implemented) group:0 (not implemented) size:4823 atime:1389062375 (2014/01/7-02:39:35) ctime:1389058500 (2014/01/7-01:35:00) mtime:1389062373 (2014/01/7-02:39:33) 1389062373 is 2014-01-07 02:39:33, so the old client is reporting the unixepoch in local time, as described in the old bug report I mentioned at the start of this email. Also, why is the "type" reported differently? (100000 versus 0x0020) Does it matter? glauber

1 0

MQ monitoring on Windows
by Neil.Simmonds＠express-gifts.co.uk 07 Jan '14

07 Jan '14

I've got a number of MQ monitors currently running on Aix and Linux but I now have a requirement to add one on a Windows client. My script for Linux looks something like this, TMPFILE="$XYMONTMP/mq-$MACHINE.$$" touch $TMPFILE echo "client $MACHINE.mqcollect mqcollect" >$TMPFILE # while [ $# != 0 ] do QMGR=$1; shift sudo -u mqm mqsc $QMGR 'display qlocal(*) curdepth' >> $TMPFILE done # $XYMON $XYMSRV "@" < $TMPFILE I'm pretty sure I can do the necessary to get the MQ data out into a temporary file, however I've only ever sent data to the server as external tests (by creating a file in the tmp directory) before whereas this seems to send it as Client data. Has anyone done anything with sending data from BBWin as client data rather than as an external test. Regards, Neil Simmonds Senior Operations Analyst (Operations Support Group) Express Gifts Limited Express House Clayton Business Park Accrington Lancashire BB5 5JY T: 01254 303092 | E: neil.simmonds at Express-Gifts.co.uk<mailto:neil.simmonds at Express-Gifts.co.uk> Name & Registered Office: EXPRESS GIFTS LIMITED, 2 GREGORY ST, HYDE, CHESHIRE, ENGLAND, SK14 4TH, Company No. 00718151. Express Gifts Limited is authorised and regulated by the Financial Services Authority -------------- NOTE: This email and any information contained within or attached in a separate file is confidential and intended solely for the Individual to whom it is addressed. The information or data included is solely for the purpose indicated or previously agreed. Any information or data included with this e-mail remains the property of Findel PLC and the recipient will refrain from utilising the information for any purpose other than that indicated and upon request will destroy the information and remove it from their records. Any views or opinions presented are solely those of the author and do not necessarily represent those of Findel PLC. If you are not the intended recipient, be advised that you have received this email in error and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. No warranties or assurances are made in relation to the safety and content of this e-mail and any attachments. No liability is accepted for any consequences arising from it. Findel Plc reserves the right to monitor all e-mail communications through its internal and external networks. If you have received this email in error please notify our IT helpdesk on +44(0) 1254 303030

2 2

xymond_channel consuming a lot of CPU?
by David.Diep＠dc.gov 07 Jan '14

07 Jan '14

Hi, I saw a little bit about this back in 8/31/12 (http://lists.xymon.com/archive/2012-August/035381.html) but it was never resolved? Has anyone else seen xymond_channel consuming so much CPU time? I can't imagine this being normal. top - 14:07:56 up 6 days, 2:52, 1 user, load average: 0.97, 0.63, 0.58 Tasks: 117 total, 2 running, 115 sleeping, 0 stopped, 0 zombie Cpu(s): 22.7%us, 26.7%sy, 0.0%ni, 49.5%id, 0.3%wa, 0.2%hi, 0.0%si, 0.7%st Mem: 245792k total, 235308k used, 10484k free, 9248k buffers Swap: 1304648k total, 96604k used, 1208044k free, 44164k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 24914 xymon 20 0 7080 1388 1148 R 98.7 0.6 22:59.70 xymond_channel 1 root 20 0 3232 504 316 S 0.0 0.2 0:01.75 init 2 root 20 0 0 0 0 S 0.0 0.0 0:00.02 kthreadd 3 root RT 0 0 0 0 S 0.0 0.0 0:00.22 migration/0 4 root 20 0 0 0 0 S 0.0 0.0 0:02.03 ksoftirqd/0 5 root RT 0 0 0 0 S 0.0 0.0 0:00.00 migration/0 6 root RT 0 0 0 0 S 0.0 0.0 0:00.22 migration/1 7 root RT 0 0 0 0 S 0.0 0.0 0:00.00 migration/1 8 root 20 0 0 0 0 S 0.0 0.0 0:01.88 ksoftirqd/1 9 root 20 0 0 0 0 S 0.0 0.0 0:48.12 events/0 10 root 20 0 0 0 0 S 0.0 0.0 0:58.04 events/1 11 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuset 12 root 20 0 0 0 0 S 0.0 0.0 0:00.00 khelper 13 root 20 0 0 0 0 S 0.0 0.0 0:00.00 netns 14 root 20 0 0 0 0 S 0.0 0.0 0:00.00 async/mgr 15 root 20 0 0 0 0 S 0.0 0.0 0:00.00 pm 16 root 20 0 0 0 0 S 0.0 0.0 0:01.54 sync_supers 17 root 20 0 0 0 0 S 0.0 0.0 0:02.81 bdi-default 18 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kintegrityd/0 19 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kintegrityd/1 20 root 20 0 0 0 0 S 0.0 0.0 0:00.32 kblockd/0 21 root 20 0 0 0 0 S 0.0 0.0 0:00.26 kblockd/1 22 root 20 0 0 0 0 S 0.0 0.0 0:00.00 md/0 23 root 20 0 0 0 0 S 0.0 0.0 0:00.00 md/1 24 root 20 0 0 0 0 S 0.0 0.0 0:00.00 md_misc/0 25 root 20 0 0 0 0 S 0.0 0.0 0:00.00 md_misc/1 26 root 20 0 0 0 0 S 0.0 0.0 0:00.10 cio 27 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cio_chp 28 root 20 0 0 0 0 S 0.0 0.0 0:01.56 appldata 29 root 20 0 0 0 0 S 0.0 0.0 0:00.38 khungtaskd 30 root 20 0 0 0 0 S 0.0 0.0 0:04.48 kswapd0 31 root 25 5 0 0 0 S 0.0 0.0 0:00.00 ksmd David Diep RHEL 6.2 for IBM zSeries Kernel: 2.6.32-358.23.2.el6.s390x Look out for those in need this winter. When the temperature or wind chill is 32?F or below, the District issues a Hypothermia Alert. For assistance during an Alert, call the Shelter Hotline<http://dhs.dc.gov/page/hypothermia-alert-plan> at 1-800-535-7252 or 311.

4 4

graphing real values with rrd
by Cedric.Steenbeke＠aznikolaas.be 04 Jan '14

04 Jan '14

Hello Xymon mailing! I'm facing the following challenge; I would like to graph the actual disk space used instead of the percentage. One of the reasons I want to do this is because I want to keep track when I last expended my disk etc... I read the rrd documentation about graphing but I can't get my head around how I can make xymon do it. Can anybody point me in the right direction? Does the default disk test from bbwin collect the right data for rrd to do this? Thanks in advance! Cedric Steenbeke Dienst Informatica AZ Nikolaas Tel: +32 3 760 28 88

3 2