Brad, I wonder if you have run in to this. I have a couple of live nodes and a couple of bogus IP addresses testing the system. When I config them for ICMP only, node.start/query_icmp.php reports them as up even though they are not. All aspects of node-runner think they are up, network dashboard, status reporting, history and node.start. Debug file shows that they responded to the ping. And yes, I did verify even though I made up the addresses from thin air, they are not in use. Any clues? Thanks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Changed error debug level to E_ALL and got no errors or warning in my logs. Debug still shows everything up. In the example below, GPRS-TEST-FAILED and GARBAGE are false nodes. GPRS-TEST is the only valid up node. I'm going to dive in to the packet construction of the query_icmp.php and insure binary compatibility between the PHP implementation and HPUX. It's not going to be easy but it's all I know to do at this point. The strangest thing is that the debug output has query times that change on each cron run. I would expect them to be constant in this scenario.
If you can think of anything else, please let me know. Thanks
I'm guessing it's an issue with one of the socket functions of php. I noticed on a test box that php was complaining about various deprecated functions in the query_icmp.php script, so maybe that's the real issue. If they're deprecated, (but still working) in linux, they might have been replaced by functions that are more compatible with HPUX.
As you'll notice from the comments in the query_icmp.php script, I didn't write the Net_Ping class. It's a well-known class that someone ported to php, and it worked in my limited test environment, so I thought it was good to go. Apparently, I'll have to go find the latest version of the original, and re-port it for our needs. At least now I have a more broad test environment.
--Brad Fears
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A little more information. I found the orginal class written by "noSanity" on php.net. I copied it to a file and executed it and no matter what IP I specified, it returned an up type response. So the problem is in the class as you suspected. I'm still working it and will let you know when I find more.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, that's the class. I liked the idea of using that class over the Net_Ping class in PEAR for the same reason "noSanity" described - no exec() or system() calls. I suppose if we can't get this figured out, we could always experiment with the PEAR version of the class instead.
--Brad Fears
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thought about the PEAR version also. I haven't worked with PEAR but I don't expect it's any different than any other class. I did find one other thing. I added error_reporting(E_ALL); to line 2 of query_icmp.php and here is the output to the debug log file. This also answered a question I had before of wheather all the php.ini directives apply to the command line. Since I didn't get these notices by enabling E_ALL in the php.ini, I guess this one has to be done by hand. I learned something new today.
Are you sure you're not running a separate php.ini for your CLI? That's what Debian does - two different php.ini files, one for the CLI and one for the web stuff.
--Brad Fears
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Good catch. I never new that the cli used a different php.ini. Actually, the cli was looking for php.ini ../php/lib and I don't even have a php.ini there. The only php.ini on my system is under my ../apache/conf where my httpd.conf points too. Thanks for enlightening me again! However, it didn't change the results of the query_icmp.php.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Brad. Just a quick update. I brough up a Red Hat 7.3 box and query_icmp.php seems to work just fine. So it must be an HP-UX issue.
The only other thing I noticed is that when the node is down and you manual poll it from the Network Dash board, I get a flash of 3 error messages that say Unable to create socket, operation not permitted on lines 19, 20 and 84 in icmp_query.php. It does not return the node to up status either even though it is up. On the next cron cycle, the device returns to up as it should. Interesting. Just FYI. PHD
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Brad, I wonder if you have run in to this. I have a couple of live nodes and a couple of bogus IP addresses testing the system. When I config them for ICMP only, node.start/query_icmp.php reports them as up even though they are not. All aspects of node-runner think they are up, network dashboard, status reporting, history and node.start. Debug file shows that they responded to the ping. And yes, I did verify even though I made up the addresses from thin air, they are not in use. Any clues? Thanks.
Not sure about this problem, but perhaps its specific to your OS. Try setting the following in your php.ini (for the cgi binary only):
error_reporting = E_ALL
I'd like to see if php is complaining about something while this is happening. Thanks.
--Brad Fears
Changed error debug level to E_ALL and got no errors or warning in my logs. Debug still shows everything up. In the example below, GPRS-TEST-FAILED and GARBAGE are false nodes. GPRS-TEST is the only valid up node. I'm going to dive in to the packet construction of the query_icmp.php and insure binary compatibility between the PHP implementation and HPUX. It's not going to be easy but it's all I know to do at this point. The strangest thing is that the debug output has query times that change on each cron run. I would expect them to be constant in this scenario.
If you can think of anything else, please let me know. Thanks
Tuesday 3/01/05 5:45 pm
Execution Time: 1 Seconds
------------------------------
Attempting query #1 of GARBAGE.CORP.COM...
GARBAGE.CORP.COM UP - Queried in: 0.084 seconds.
Attempting query #1 of GPRS-TEST-FAILED.CORP.COM...
GPRS-TEST-FAILED.CORP.COM UP - Queried in: 0.353 seconds.
Attempting query #1 of GPRS-TEST.CORP.COM...
GPRS-TEST.CORP.COM UP - Queried in: 0.646 seconds.
Tuesday 3/01/05 5:50 pm
Execution Time: 1 Seconds
------------------------------
Attempting query #1 of GARBAGE.CORP.COM...
GARBAGE.CORP.COM UP - Queried in: 0.057 seconds.
Attempting query #1 of GPRS-TEST-FAILED.CORP.COM...
GPRS-TEST-FAILED.CORP.COM UP - Queried in: 0.352 seconds.
Attempting query #1 of GPRS-TEST.CORP.COM...
GPRS-TEST.CORP.COM UP - Queried in: 0.646 seconds.
I'm guessing it's an issue with one of the socket functions of php. I noticed on a test box that php was complaining about various deprecated functions in the query_icmp.php script, so maybe that's the real issue. If they're deprecated, (but still working) in linux, they might have been replaced by functions that are more compatible with HPUX.
As you'll notice from the comments in the query_icmp.php script, I didn't write the Net_Ping class. It's a well-known class that someone ported to php, and it worked in my limited test environment, so I thought it was good to go. Apparently, I'll have to go find the latest version of the original, and re-port it for our needs. At least now I have a more broad test environment.
--Brad Fears
I'll look also. Thanks
A little more information. I found the orginal class written by "noSanity" on php.net. I copied it to a file and executed it and no matter what IP I specified, it returned an up type response. So the problem is in the class as you suspected. I'm still working it and will let you know when I find more.
Yes, that's the class. I liked the idea of using that class over the Net_Ping class in PEAR for the same reason "noSanity" described - no exec() or system() calls. I suppose if we can't get this figured out, we could always experiment with the PEAR version of the class instead.
--Brad Fears
Thought about the PEAR version also. I haven't worked with PEAR but I don't expect it's any different than any other class. I did find one other thing. I added error_reporting(E_ALL); to line 2 of query_icmp.php and here is the output to the debug log file. This also answered a question I had before of wheather all the php.ini directives apply to the command line. Since I didn't get these notices by enabling E_ALL in the php.ini, I guess this one has to be done by hand. I learned something new today.
Wednesday 3/02/05 2:50 pm
Execution Time: 1 Seconds
------------------------------
Attempting query #1 of GARBAGE.CORP.COM...
Notice: Undefined variable: sum in /usr/local/gprs/include/query_icmp.php on line 31
GARBAGE.CORP.COM UP - Queried in: 0.049 seconds.
Attempting query #1 of GPRS-TEST-FAILED.CORP.COM...
Notice: Undefined variable: sum in /usr/local/gprs/include/query_icmp.php on line 31
GPRS-TEST-FAILED.CORP.COM UP - Queried in: 0.174 seconds.
Attempting query #1 of GPRS-TEST.CORP.COM...
Notice: Undefined variable: sum in /usr/local/gprs/include/query_icmp.php on line 31
GPRS-TEST.CORP.COM UP - Queried in: 0.097 seconds.
Wednesday 3/02/05 2:55 pm
Execution Time: 0 Seconds
------------------------------
Are you sure you're not running a separate php.ini for your CLI? That's what Debian does - two different php.ini files, one for the CLI and one for the web stuff.
--Brad Fears
Good catch. I never new that the cli used a different php.ini. Actually, the cli was looking for php.ini ../php/lib and I don't even have a php.ini there. The only php.ini on my system is under my ../apache/conf where my httpd.conf points too. Thanks for enlightening me again! However, it didn't change the results of the query_icmp.php.
Hi Brad. Just a quick update. I brough up a Red Hat 7.3 box and query_icmp.php seems to work just fine. So it must be an HP-UX issue.
The only other thing I noticed is that when the node is down and you manual poll it from the Network Dash board, I get a flash of 3 error messages that say Unable to create socket, operation not permitted on lines 19, 20 and 84 in icmp_query.php. It does not return the node to up status either even though it is up. On the next cron cycle, the device returns to up as it should. Interesting. Just FYI. PHD