(No output on stdout) stderr: on second check

[almonitoradmin]

Yeah. I tried swapping the ip addresses in the configuration of nagios, and I found that the error followed the swap: pgqawww02 was erroring initially but when I changed the ip in the nagios to point to pgqawww01 it started working fine. So there does appear to be something special about the output coming back from the machine that the module does not like.

Code: Select all

[root@usawexx011 ~]# curl -u statususer:mypass "http://10.x.x.1/server-status?auto"
Total Accesses: 562
Total kBytes: 3557
CPULoad: .0386313
Uptime: 36706
ReqPerSec: .0153108
BytesPerSec: 99.2309
BytesPerReq: 6481.08
BusyWorkers: 17
IdleWorkers: 6
Scoreboard: R_RRRR_.RRR_R_R_RRW_R.RR.R......................................................................................................................................................................................................................................
[root@usawepvl011 ~]# echo $?
0
[root@usawexx011 ~]# curl -u statususer:mypass "http://10.x.x.2/server-status?auto"
Total Accesses: 583
Total kBytes: 2378
CPULoad: .0274612
Uptime: 36852
ReqPerSec: .01582
BytesPerSec: 66.0771
BytesPerReq: 4176.8
BusyWorkers: 21
IdleWorkers: 5
Scoreboard: _RRRR_R__RR_RRRRRRRRRRRW.R.R....................................................................................................................................................................................................................................
[root@usawexx011 ~]# echo $?
0

[hsmith]

Yeah. I tried swapping the ip addresses in the configuration of nagios, and I found that the error followed the swap: pgqawww02 was erroring initially but when I changed the ip in the nagios to point to pgqawww01 it started working fine. So there does appear to be something special about the output coming back from the machine that the module does not like.

Code: Select all

[root@usawexx011 ~]# curl -u statususer:mypass "http://10.x.x.1/server-status?auto"
Total Accesses: 562
Total kBytes: 3557
CPULoad: .0386313
Uptime: 36706
ReqPerSec: .0153108
BytesPerSec: 99.2309
BytesPerReq: 6481.08
BusyWorkers: 17
IdleWorkers: 6
Scoreboard: R_RRRR_.RRR_R_R_RRW_R.RR.R......................................................................................................................................................................................................................................
[root@usawepvl011 ~]# echo $?
0
[root@usawexx011 ~]# curl -u statususer:mypass "http://10.x.x.2/server-status?auto"
Total Accesses: 583
Total kBytes: 2378
CPULoad: .0274612
Uptime: 36852
ReqPerSec: .01582
BytesPerSec: 66.0771
BytesPerReq: 4176.8
BusyWorkers: 21
IdleWorkers: 5
Scoreboard: _RRRR_R__RR_RRRRRRRRRRRW.R.R....................................................................................................................................................................................................................................
[root@usawexx011 ~]# echo $?
0

What are you trying to monitor here, exactly? Is there another plugin that fits your criteria? It looks like the last update to the one that you are using was in 2009. We can try to help you find a different plugin.

[almonitoradmin]

Well I think I'm going to hoist the white flag and surrender on this one. I did run curl on the command line to compare the output I was getting back from apache and they are basically identical. Since then I've added this same check to 2 other servers and it works fine on both of them. We can get by without running this test on the server that's failing because it's in our QA environment, not prod...so monitoring it won't be necessary.

Thanks for your efforts.

[hsmith]

Well I think I'm going to hoist the white flag and surrender on this one. I did run curl on the command line to compare the output I was getting back from apache and they are basically identical. Since then I've added this same check to 2 other servers and it works fine on both of them. We can get by without running this test on the server that's failing because it's in our QA environment, not prod...so monitoring it won't be necessary.

Thanks for your efforts.

Not the answer we were hoping for . Sorry we couldn't make too any progress on this one. We can try to work on this some more if you'd like, but it sounds like that's not the case. Please let me know if we are all right to lock this topic up.