[SUMMARY] solaris10, 2.03b, 1.4 check_disk state flap

[Subhendu Ghosh]

On Tue, 26 Apr 2005, Marc Belanger wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Wrapping up a few threads here. Specifically:
> https://sourceforge.net/mailarchive/forum.php?thread_id=7119249&forum_id=187
> 3
> https://sourceforge.net/mailarchive/forum.php?thread_id=7119859&forum_id=187
> 3
> https://sourceforge.net/mailarchive/forum.php?thread_id=7097312&forum_id=187
> 3
>
> I got it worked out. Here are the details and idle observation.
>
> 1) If I start nagios and ignore it for some time, it works itself out for
> the most part. Using the command locally or via services.cfg |
> checkcommands.cfg:
> check_by_ssh -H <host> -S 18 -C "/usr/local/nagios/libexec/check_disk -w
> 10% -c 5% -p /tmp"
>
> 	*note: Only one specified mount. See below.
>
> 2) If I specify swap or tmp based mounts, Nagios has lots of trouble. The
> command line will continue to work (as a one shot), but if I run it through
> services.cfg | checkcommands.cfg, the state flaps intermittantly, but the
> result data stays the same. Using the example:
> check_by_ssh -H <host> -S 18 -C "/usr/local/nagios/libexec/check_disk -w
> 10% -c 5% -p / -p /tmp"
>
> The state will flap intermittently, and eventually post a flap warning.
>
> 3) If I break up the mounts into separate services, for some odd reason, it
> loves life, and works; no weird or unexpected results on the web console,
> regardless of the parameters I feed it.
>
> check-root-space = check_disk -w 10% -c 5% -p /
> check-home-space = check_disk -w 10% -c 5% -p /export/home
> check-var-space = check_disk -w 10% -c 5% -p /var
> check-swap-space = check_swap -w 10% -c 5%
>
> 4) check_disk does not seem to like working with anything mounted as|to
> swap, I had similar results using /var/run as a target (for example). The
> plugin, check_swap, is much better at this, but does not provide the "df -k
> like" percentage results for /tmp specifically.
>
> 5) Sending a passive check via the console in most cases, stopped the
> flapping and reset the correct state. I would run the command on the
> target_host, and paste the results into the "plugin result" box.
>
> 6) Regarding retention.dat, status.dat; it did me no good to cp /dev/null to
> them and restart nagios. It also didn't  change my results when I turned off
> the retention saving/discarding parameters. Lastly, it did not come down to
> file perms as I had early on set them to nagios:nagios 777. The correct, or
> incorrect state followed the usage of the plugin; see #3 for how it all
> worked out happy-happy, nice-nice.
>
> I completely expect and understand some folks are using 2.03b|1.4 check_disk
> without the weirdness I've seen.
>
> I'm not saying something is broken, although it might be; I'm not
> knowledgeable enough to see how (my coding expertise grinds to a screeching
> halt at shell, basically), nor have I gotten many requests for more
> information. I've tried to provide enough pertinent data/config/etc for
> those that wanted to pursue further, and I'll happily provide what I
> have/know if anyone asks.
>
> - -Marc
>
> #
> # PGP Public Key:   bru1n (at) comcast (dot) net
> # E8E9 FAC2 1552 DC29 7D53 FD1E 6AAE 4CA9 E5FE B976
> #
>

Thanks for the concise summary. So it looks like we need a little more 
work for memory based partitions in Solaris.

Did you have GNU df or Solaris df being used by check_disk?
strings check_disk | grep df

-- 
-sg


-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans!
Take this survey and enter to win a one-year sub to SourceForge.net
Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start!  http://www.idcswdc.com/cgi-bin/survey?id=105hix
_______________________________________________
Nagios-users mailing list
Nagios-users at 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