Dear PHP Server Monitor Developer
Thank you very much for this great tool. I use the old version since years and have now updated to the new release (completely new installation). Now I have the following problem:
I have 3 webservers with DynDNS-adresses (.no-ip.org and .dynvpn.de). For testing reasons there are also 2 public webservers (google.ch and my own webadress). If I use the update-button in the tool, then every server is online and green. If I wait for the command from the Cron-Job, then just the two public servers seems to be online, not the DynDNS-adresses webservers. Is there a problem with subdomains? What can I do to fix that issue?
Thank you, regards
Thanks for using this tool, hope you like the new version.
There should not be any problem with subdomains, and the "Update" button does exactly the same thing as the cronjob so that should not really make any difference. What is the error given as to why these servers are down?
You can have a look under Logs to see any errors that have occured.
I assume for all servers the "Monitoring?" setting has been set to "Yes"?
Hi, thank you for your fast answer.
If I press the Update Button, then I see the following Log entry: "Server 'XX' is RUNNING: ip=XX, port=0"
If I wait for the Cron-Job, then I see the following Log entry: "Server 'XX' is DOWN: ip=XX, port=0. Error=no response from server"
Yes, all the servers are enabled for monitoring and mail alerting.
to clarify my problem I created a short video (attached). You can see, it works when I press the update button. The cronjob is set to 1 minute and work withou any problem for google, but not for my own webservices. The target of the dyn-link is a pfsense firewall with an open port 80 from the source of the monitoring website. In the firewall-logs I can see the the connection attempts from the cronjob and it is allowed from the firewall.
Do you have an idea, how I can correct this issue? On the earlier versions of Server Monitor it worked without any issues.
That is quite interesting. I am not sure what would cause this. Did you try changing them to "service" type with port 80? That might help.
Could you please let me know what your set up is (OS, PHP version, apache module vs fast cgi)?
very interesting... with "service" on port 80 it works fine. What is the difference?
PHP Version: 5.3.28
OS: Linux Debian
Apache: Apache (don't know the version)
Fast CGI: CGI/1.1 (not sure)
If you send me a message with your e-mail address, than I could send you the php_info export.
The "website" type attempts to open a regular web page, just like you do in your browser. It will retrieve its contents, and also check the HTTP status code (for example "404 not found" will cause an error). You can then even add a check to make sure the content of the website includes a certain string or matches a certain regular expression.
The "service" type only attempts to connect to the IP address and specified port to check whether the server is listening on that port. For example, if you are running a webserver it will usually listen on port 80 for incoming connections. So if the monitor is able to connect to the server on port 80, you know the webserver is running and accepting connections. It does not, however, mean that your website is available to your users, because it might have PHP errors or database problems. This can be monitored using the website type with a pattern search as described above.
In regard to your phpinfo, there might be a difference between the configuration used in CLI (command line) mode and fcgi mode. Could you mail a phpinfo from both to ipdope <at> users.sourceforge.net?
thank you for this clarification. Now I understand the difference between service 80 and Website. For me would the port 80 service monitoring be enough.
But although it would be interesting, why this error occurs. Regarding the phpinfo I contacted you over the sourcforge.net channel.
Best regards, foxworker
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.