How exactly does ISPConfig detect that the web server is online / offline in the "Monitor" module? Because, basically, one of my servers is coming up red for error, supposedly because the web server is "offline", but this is definitely not accurate information as that server is serving files (to diagnose potential faults with the load balancing I'm using, each of my web servers adds an extra header identifying itself, so I can directly see that it's very much online and responding) and if I login to that server directly and "service apache2 status" then it's up and running. So I'm just wondering how ISPConfig determines whether a web server is "offline / online" for the Monitor module with a view to working out why it's getting this wrong, so I can fix it. The false positive leaves it showing red constantly, which risks me not seeing a genuine error, as I've learnt to ignore the error because it isn't real.
ISPConfig checks if a service is listening on the standard port of that service on localhost. If it shows apache offline, then there is probably no service listening on localhost port 80.
Well, looking at "netstat", I'm seeing something listening on tcp6 port 80. I presume it's "tcp6" as a catchall for both IPv4 and IPv6, as this system (Ubuntu) can do the IPv4-over-IPv6 mapping thing. And, as I say, Apache is definitely up and running on this problem node, as I'm getting websites served. 100% with no issues. It's only that ISPConfig isn't reporting that accurately in "Monitor" and I'm not entirely sure why. Particularly because I have more than one web server and the other one - which is identical hardware, distro and everything - is coming up as fine. I mean, I'm sure it's some kind of configuration mistake on my end of things. And it's not actually affecting the operation of things. But I'd love to know why it's doing this.
Well, I specifically used "sudo netstat -ntap | grep :80 | grep LISTEN" to whittle down the output (as process ids coincidentally with "80" in them were also coming up and such). But here's what I got: Code: tcp6 0 0 :::80 :::* LISTEN 12752/apache2 And this same command on the other node - which is reported by ISPConfig as fine - produces the same output (save that, of course, the pid is naturally different).
