On Aug 15, 2008, at 5:47 PM, Hugo van der Kooij wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Marc Powell wrote:
> | $LASTHOSTSTATECHANGE$ This is a timestamp in time_t format > (seconds > | since the UNIX epoch) indicating the time the host last changed > state. > | $LASTHOSTUP$ This is a timestamp in time_t format (seconds > since the > | UNIX epoch) indicating the time at which the host was last > detected as > | being in an UP state. > > I recall that $LASTHOSTSTATECHANGE$ only worked to indicate the > previous > working period on a down message but the up message showed a bogus > counter (being 0 or close to zero). So that variable is not that > usefull. That would be an order-of-operations bug then, IMHO. The variables should not be updated before a notification is sent or they do become useless. You know by the fact that you received a recovery notification that it just changed to an OK state. I can't explicitly test this since I don't use host checks and I'm not using 3.x yet. > I for one would not care about how long the UP period was but I do > care > about the DOWN period. But I have not yet found a way to add it to the > report. Assuming that the above macro works as advertised, it would be trivial -- notification command { echo " ...\n Duration of downtime was $$((`/bin/date +%s` - $LASTHOSTUP $)) seconds, starting around `/bin/date -d '1970-01-01 UTC $LASTHOSTUP $ sec'`" | mail -s ... -- Marc ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ 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