Nagios Support Forum

abrist wrote:It could be in one of these locations:

Code: Select all

/etc/php/php.ini
/etc/php5/php.ini
/usr/bin/php5/bin/php.ini

Yeah, it sure is Should I set that as "Europe/Lisbon"?

abrist wrote: You should be able to set your localtime in ubuntu with the utility "tzconfig

I got a strange output from that apparently standard command

abrist wrote:Service checks are delayed by an inconsistent amount.

Well, those service checks are not simply late, some of them are still pending since last friday :: 458 OK (but somewhat delayed) and 246 still pending

sebastiaopburnay wrote:Should I set that as "Europe/Lisbon"?

Yes, set it in: But this probably will not fix the issues as host checks are working.
You should be able to still use the tzconfig, otherwise you will need to install tzdata or change the loccaltime by hand.

Just to check one last time: all these checks are active checks correct?

abrist wrote:Just to check one last time: all these checks are active checks correct?

Yep, and the template is the same for all service checks...

I've just tried the same configs on the same host with the more primitive VM and checks began working as scheduled.

Major changes:
- VM's OS good: Ubuntu 10.04 32bit ; bad: Ubuntu 12.04 64bit
- Nagios': good 3.3.1 ; bad: 3.4.1

hmmmm. Could you upgrade the test (working) box to 3.4.1 and test once more? This is most likely either a very obscure bug in 3.4.1 or a system problem . . .

abrist wrote:Could you upgrade the test (working) box to 3.4.1 and test once more? . . .

Yes, it crossed my mind, will give it a go.

It's been three years since I began working with Nagios and this issue is the most stupid (as in not explainable) issue I've seen ever since.

I will leave the office to get diner and I will try it later at home.

Thank you for the feedback

No problem, thanks for the patience

We leave the office at 5pm central, so we may have to catch up tomorrow after 9am central.

Hey, I've remembered that instead of upgrading Nagios on the working old VM, I will try to downgrade nagios in the new (not working so well) VM's.

Meanwhile I've noticed that the few service checks being executed, all appear in the web interface's 'Performance Info' page as been passively checked
(I have both active and passive checks enabled for all service and host checks in order to be able to submit some custom states/outputs from time to time)

Well, I have configured several Nagios (3.3.1 or 3.2.3) remote monitoring servers feeding my central instance and it is standard for us to have those two options enabled (active and service checks) for the same object (host/service).

After disabling passive service checks on this missbehaving Nagios 3.4.1, the scheduling queue began working semi-properly and Nagios began actively checking my services.

Could it be that from 3.4.x, Nagios became unable to use simultaneously active and passive checks for the same service object without compromising the scheduling engine?

This issue is really bizar and intriguing. I'm just hoping it aint about some dumb/missused configuring flag.

sebastiaopburnay wrote:Could it be that from 3.4.x, Nagios became unable to use simultaneously active and passive checks for the same service object without compromising the scheduling engine?

Core should be able to do both passive and active for each host.

This issue is really bizar and intriguing. I'm just hoping it aint about some dumb/missused configuring flag.

If you want, post a config for one of the misbehaving passive checks (from the remote and the service/command config on the nagios server).

Well... it has gone really stable and normal (Nagios-Like )now that I've gone from: To: In all my templates.... as the demonstration will be this thursday, and I still have some of the 700.. service checks with bad outputs, I will have to dedicate the enxt days to fixing those,

Nevertheless, I'm planing on testing this 'eventual' gap on Nagios' 3.4.x versions later on, in a lab environment.

It is not critic to me right now, because I'm concentrating all those checks on a central Nagios Server who does all the notifications and persistence.

I will not migrate my central Nagios to 3.4.x, since there I necessarly need to use both passive and active checks and I'm unsure of the reasons behind this apparent conflict of configurations against the scheduling logic.

PS
i) Thank you very much for the time, effort and synapses on this still unexplained and sort of unresolved issue
ii) This is still an open issue/discussion

This is definitely interesting. I will try to see if I can reproduce it on my core boxes. It may be a rather deep config issue that is causing it though as many, many people run both active and passive checks. Let us know if your focused testing reveals anything.