reported service state id when pending

[kaos]

Hi,

I have a bunch of services that are only passively checked, and a few active services to monitor the passive ones.

Initially, all services are in a pending state (as they should be).

Now, when the few active services' checks run, I pass along the state id for the passive checks that should be monitored, using a bunch of $SERVICESTATEID:some.host:passive-service-desc$ macros.
The interesting fact here is, that all passive services in a pending state, are reported as... OK (!)

I know there is no state id representing pending, but perhaps state id 3 (Unknown) would be a better choice in this case.

This is easily verified when looking at the status.dat file, where I find `current_state=0` for services with `has_been_checked=0`. I don't see any macro for getting this information, though :/ (wether a service is in a pending state or not).

I'm a developer, so I'm not unfamiliar with the thought of diving in and fixing this myself, but would like to know if I'm missing something etc, as I'm rather new to nagios.

Perhaps it would make sense to introduce a new state id (say, 4), that represent this pending state. It should not be accepted as a result from running a command, only in cases where the current state is to be determined.

Any thoughts?

[slansing]

Hmm, can you provide an example of one of your active checks that you are running against passive hosts/services? Is the goal of the active check just to determine their state? Otherwise you may be better off using freshness checks on them if you have not looked into that yet:

http://nagios.sourceforge.net/docs/3_0/freshness.html

[kaos]

Sorry, I would have posted this earlier, but the op was being held in moderation until after I left work..

The goal is to check their state (and the $SERVICEOUTPUT$ data, in case state is OK).

However, I missed the `initial_state` setting while searching the docs regarding this, which solves my issue entirely, by setting 'initial_state u' (which to me would seem like a saner default value for initial_state, imho)

Although, I don't seem to get the initial_state to propagate to the object.cache file.. but that's another issue.

[tmcdonald]

Are you saying the initial_state is not entering objects.cache even after a restart of nagios? What happens when you delete objects.cache after stopping nagios, then start nagios again?

And as for the default state, I can only assume the default of OK is to avoid sending out emails for UNKNOWN states.

[kaos]

Are you saying the initial_state is not entering objects.cache even after a restart of nagios? What happens when you delete objects.cache after stopping nagios, then start nagios again?

And as for the default state, I can only assume the default of OK is to avoid sending out emails for UNKNOWN states.

Yes, I've tried to delete the object.cache file, and it still gets recreated with initial_state o in it.. :/
I even tried to get rid of the object.precache, but that didn't seem to make any difference either..

Regarding default state, it would seem a bit silly to send out notifications for a service that has not had any checks performed yet, regardless of initial state, unless perhaps it fails its freshness check.. (that won't be an issue in my case, though, as I have notifications disabled on the concerned services..)

[tmcdonald]

I'm seeing the same thing for initial_state as well... I've filed a bug report for this. ID 3508 for reference.

And I will see if I can get a dev to weigh in on this.

[kaos]

Cool. Is it on a public tracker?

Didn't seem to be a valid issue # on tracker.nagios.org.

[slansing]

Ah, he must have filed it internally, he is out for the day. We've generally been moving more intricate bugs to our internal system so the devs can tack right onto it.