Re: [Nagios-users] R: check_nt : segmentation fault
It's a bummer you can't upgrade to 3.x... I'm not sure if anyone still uses Nagios 1.x on a 64bit machine. Maybe this is a problem of the old Nagios (core) version itself? You can just for the fun of it install a new Nagios 3.x on a similar machine and just set up some basic configuration to compare the syslogs of both machines. On Thu, Jan 19, 2012 at 9:34 AM, Marco Borsani m.bors...@it.net wrote: I can't upgrade to 3. I compiled nagios and plugins on the new HW, not copied them from the older server. It seems that check_nt run correctly, but I still receive those errors in the syslog. -Messaggio originale- Da: Assaf Flatto [mailto:nag...@flatto.net] Inviato: mercoledì 18 gennaio 2012 16:47 A: Nagios Users List Oggetto: Re: [Nagios-users] check_nt : segmentation fault Please tell me that the nagios version is a typo. if not , you should upgrade to version 3 , and the sooner the better . Since check_nt is communicating with windows server was there any change on the MS platforms ? Did you compile the chdck_nt for the old machine , and just copied across ? Marco Borsani wrote: Hi all Nagios server: 1.4.1 Nagios plugins : 1.4.15 SO: Centos 5.7 64bit I still receive this errors (but check_nt runs on every server): check_nt[10383]: segfault at rip 00394a637a04 rsp 7fff6bf3d3e0 error 4 check_nt[15038]: segfault at rip 00394a637a04 rsp 7fff90fe42a0 error 4 check_nt[19873]: segfault at rip 00394a637a04 rsp 7fff222f89b0 error 4 check_nt[24428]: segfault at rip 00394a637a04 rsp 7d838f10 error 4 check_nt[29177]: segfault at rip 00394a637a04 rsp 7fffaad060c0 error 4 check_nt[1510]: segfault at rip 00394a637a04 rsp 7fffb8555450 error 4 check_nt[6387]: segfault at rip 00394a637a04 rsp 7fff42383290 error 4 check_nt[11234]: segfault at rip 00394a637a04 rsp 7fff15652e90 error 4 check_nt[20926]: segfault at rip 00394a637a04 rsp 7fffc118f5b0 error 4 check_nt[25407]: segfault at rip 00394a637a04 rsp 7fffd984fec0 error 4 check_nt[30172]: segfault at rip 00394a637a04 rsp 7fff847a95d0 error 4 check_nt[2476]: segfault at rip 00394a637a04 rsp 7fff4fc15250 error 4 ……….. Before, with same Nagios releases, but with another hardware (and centos 5.3 32 bit), no erros. Any idea ? Marco Borsani *Unix and Monitoring Sysadmin* *Technical Operations Dpt.* tel: +39 010 4310115 fax: +39 02 30130311 cell: +39 329 5953944 ITnet Srl Società con socio unico Direzione e Coordinamento di … -- -- -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d -- -- ___ Nagios-users mailing list Nagios-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nagios-users ::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. ::: Messages without supporting info will risk being sent to /dev/null -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Nagios-users mailing list Nagios-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nagios-users ::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. ::: Messages without supporting info will risk being sent to /dev/null -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Nagios-users mailing list
[Nagios-users] Availability data from avail.cgi often incorrect due to 'SOFT' OK messages
I've been working on the cause of this issue for a few months and just today had time to really dig in and science it. When we pull data from avail.cgi for reporting, often times a host that was recently rebooted will show some services CRITICAL from the reboot until the midnight log rotation for that day. After some manual editing of the archived history logs that avail.cgi is reading, I found that this happens when a post-reboot service check logs a 'soft' OK but doesn't happen for 'hard' OK messages. Right now I've implemented a cron to run post-archive and simply convert all SOFT OK entries to HARD OK entries, which has made my data correct to the best of my knowledge. I just have a couple questions about this: 1) Is this skewing my data in any way? The timestamps look right based on the observed length of service outage after doing this. 2) Is this a bug in avail.cgi or in the actual logging of this data? Should there have been a second HARD OK status entry in the log or was the first entry supposed to be HARD? Also, I am on an older version of nagios than current (3.2.3). If I've wasted my time working around something fixed in a more recent version, please let me know. I'd prefer not to upgrade unless necessary as the version we're on has been very stable excepting this one bug. -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Nagios-users mailing list Nagios-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nagios-users ::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. ::: Messages without supporting info will risk being sent to /dev/null
[Nagios-users] question about check_disk
Hi, Please help See this output: $ df -h /S00022_BACKUP Filesystem size used avail capacity Mounted on S00022_BACKUP 2.6T94G 307G24%/S00022_BACKUP $ plugins/check_disk -E -w 20% -c 10% -W 10% -K 8% -u MB -p /S00022_BACKUP DISK OK - free space: /S00022_BACKUP 314182 MB (76% inode=99%);| /S00022_BACKUP=95885MB;328053;36906 0;0;410067 $ zpool list S00022_BACKUP NAMESIZE ALLOC FREECAP HEALTH ALTROOT S00022_BACKUP 2.66T 2.32T 349G87% ONLINE - df says FS is 24% free, so no problem. Check_disk says 76% full, so that matches, still no problem. Assuming inode=99% reports inode table 99% full (!) I would expect a warning/critical from '-W 10% -K 8%' but it does not do that. 'zpool list' shows '87%' which is totally different. -Am I interpreting the info wrong? -How can I dig up more detailed info on inode usage in a zpool? -What causes the difference between 'df -h' and 'check_disk' on one side and 'zpool list' on the other side? Regards, Harm B. J. Ensing unix system administrator T: +31 (0) 8826 51609 M: +31 (0) 6 5158 4736 harm.ens...@atos.netmailto:bert.keu...@atos.net team 3 group North51 T: +31 (0) 8826 51617 gmnl-uxonort...@atos.netmailto:bert.keu...@atos.net Henri Dunantlaan 2 9728 HD Groningen http://www.atos.net [cid:image002.png@01CCD75C.18917250] Dit bericht is vertrouwelijk en kan geheime informatie bevatten enkel bestemd voor de geadresseerde. Indien dit bericht niet voor u is bestemd, verzoeken wij u dit onmiddellijk aan ons te melden en het bericht te vernietigen. Aangezien de integriteit van het bericht niet veilig gesteld is middels verzending via internet, kan Atos Nederland B.V. niet aansprakelijk worden gehouden voor de inhoud daarvan. Hoewel wij ons inspannen een virusvrij netwerk te hanteren, geven wij geen enkele garantie dat dit bericht virusvrij is, noch aanvaarden wij enige aansprakelijkheid voor de mogelijke aanwezigheid van een virus in dit bericht. Op al onze rechtsverhoudingen, aanbiedingen en overeenkomsten waaronder Atos Nederland B.V. goederen en/of diensten levert zijn met uitsluiting van alle andere voorwaarden de Leveringsvoorwaarden van Atos Nederland B.V. van toepassing. Deze worden u op aanvraag direct kosteloos toegezonden. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos Nederland B.V. group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. On all offers and agreements under which Atos Nederland B.V. supplies goods and/or services of whatever nature, the Terms of Delivery from Atos Nederland B.V. exclusively apply. The Terms of Delivery shall be promptly submitted to you on your request. Atos Nederland B.V. / Utrecht KvK Utrecht 30132762 inline: image001.pnginline: image002.png-- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d___ Nagios-users mailing list Nagios-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nagios-users ::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. ::: Messages without supporting info will risk being sent to /dev/null
Re: [Nagios-users] question about check_disk
You have it backwards. 'df' says 24% used, not remaining. 'check_disk' shows how much is remaining (76% and 99% in this case). I've never liked how check_disk displays its results by default, most Unix tools show as a primary metric how much of a resource is used and not how much is remaining. It always looks wrong. Jeffrey. On Fri, Jan 20, 2012 at 3:18 AM, Ensing, Harm harm.ens...@atos.net wrote: Hi, Please help See this output: $ df -h /S00022_BACKUP Filesystem size used avail capacity Mounted on S00022_BACKUP 2.6T94G 307G24%/S00022_BACKUP $ plugins/check_disk -E -w 20% -c 10% -W 10% -K 8% -u MB -p /S00022_BACKUP DISK OK - free space: /S00022_BACKUP 314182 MB (76% inode=99%);| /S00022_BACKUP=95885MB;328053;36906 0;0;410067 $ zpool list S00022_BACKUP NAMESIZE ALLOC FREECAP HEALTH ALTROOT S00022_BACKUP 2.66T 2.32T 349G87% ONLINE - df says FS is 24% free, so no problem. Check_disk says 76% full, so that matches, still no problem. Assuming inode=99% reports inode table 99% full (!) I would expect a warning/critical from ‘-W 10% -K 8%’ but it does not do that. ‘zpool list’ shows ‘87%’ which is totally different. -Am I interpreting the info wrong? -How can I dig up more detailed info on inode usage in a zpool? -What causes the difference between ‘df –h’ and ‘check_disk’ on one side and ‘zpool list’ on the other side? -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d___ Nagios-users mailing list Nagios-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nagios-users ::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. ::: Messages without supporting info will risk being sent to /dev/null
