I am using Monit v5.5 and trying to set a check for apache. Everything below is as per the documentation. However, when i say monit -t, i get /etc/monit.conf:155: Error: syntax error 'http' which points to the HTTP HEADERS line. Commenting it out works fine. Same issue with content = "WrongPath". Can anybody point me in the right direction?
check host mysite with address mysite.com
start program = "/usr/sbin/httpd start"
stop program = "/usr/sbin/httpd stop"
if failed port 80 protocol http
with http headers [Host: mysite.com, Cache-Control: no-cache]
and request "/pingtest.html" with content = "WrongPath"
then restart
if 5 restarts within 10 cycles then timeout
Your version is too old, HTTP HEADERS feature is in version 5.9. Please read this.
Related
I've been struggling with this issue for 2 days now and it's starting to be a big problem.
we have 2 LB on which HAproxy is installed,
I've tried to change the certificats on the first one and it fell down and couldn't restart it even when getting back the old haproxy.cfg file.
after a while I tried to restart the server and it did the job. I had my Haproxy running on the failed node. and I successfully changed the ssl certificats on that one.
Then, I tried to do the same on the second, and then it went down and nothing seem to be correcting the problem; not restarting haproxy on the old haproxy.cfg file nor restarting the whole server.
the error I get is like this :
Starting frontend PAGEMAINTENANC_GUN: cannot bind socket [10.168.10.16:80]
Can you please give me some little help?
thank you all in advance.
It seems that I've been trying to bind to an IP address that is not local. That's why the HAproxy fails to start. The solution was to set ip_nonlocal_bind to 1.
To get info:
sysctl net.ipv4.ip_nonlocal_bind
Set net.ipv4.ip_nonlocal_bind to 1
sysctl -w net.ipv4.ip_nonlocal_bind=1
Restart HAproxy works
Can someone please let me know on what basis monit decides that its time to restart an application? For instance, if I want monit to monitor my web application, what information should I provide to monit based on which it will restart?
thanks
Update:
I was able to kind of make it work using the following monit config
check host altamides with address web.dev1.ams
if failed port 80 with protocol http
then alert
However, I was wondering if I can use any absolute URL of my application. Something like http://foo:5453/test/url/1.html/
Can someone help me on that please?
Monit by himself will not restart any service, but you can provide to it the rules you want to perform it, you can do something like
check process couchdb with pidfile /usr/local/var/run/couchdb/couchdb.pid
start program = "/etc/init.d/couchdb start"
stop program = "/etc/init.d/couchdb stop"
if cpu > 60% for 2 cycles then alert
if cpu > 80% for 5 cycles then restart
if memory usage > 70% MB for 5 cycles then restart
check host mmonit.com with address mmonit.com
if failed port 80 protocol http then alert
if failed port 443 protocol https then alert
I figured the answer from monit help page
if failed
port 80
protocol http
request "/data/show?a=b&c=d"
then restart
I'm using the following monit code to alert if the specified page isn't answering with http 200 status code:
check host gateway with address 127.0.0.1
if failed
port 7778
protocol http
request "/mypage/"
status = 200
then alert
Anyway, on monit 5.20 (default on my debian 9) I'm getting: FAILED to [127.0.0.1]:7778/mypage/ type TCP/IP protocol HTTP, why?
Editing: it seems related to the status getting back, which is 301, but still haven't figured out the reason.
At the end I couldn't find the reason, but upgrading to latest monit version (5.26) the issue disappeared.
I have a functional app running in a docker on port 3000. I have selenium tests that works when I set my host to http://localhost:3000. I created a container to launch the selenium tests and it fails with the following error:
WebDriverError:Reachederrorpage:about:neterror?e=nssFailure2&u=https://app:3000/&c=UTF-8&f=regular&d=An error occurred during a connection to app:3000.
SSL received a record that exceeded the maximum permissible length.
Error code: <a id="errorCode" title="SSL_ERROR_RX_RECORD_TOO_LONG">SSL_ERROR_RX_RECORD_TOO_LONG</a>
Snippet of my docker-compose.yml
app:
build:
context: .
dockerfile: Dockerfile.dev
volumes:
- ./:/usr/src/app/
ports:
- "3000:3000"
- "3001:3001"
networks:
tests:
selenium-tester:
build:
context: .
dockerfile: Dockerfile.selenium.tests
volumes:
- ./:/usr/src/app/
- /dev/shm:/dev/shm
depends_on:
- app
networks:
tests:
I replaced the host by http://app:3000 but firefox seems to want to redirect this http to https (which is not working). And finally I build my driver like this:
const ffoptions = new firefox.Options()
.headless()
.setPreference('browser.urlbar.autoFill', 'false'); // test to disable auto https redirect… not working obviously
const driver = Builder()
.setFirefoxOptions(ffoptions)
.forBrowser('firefox')
.build();
When manually contacting the http://app:3000 using curl inside the selenium-tester container it works as expected, I get my homepage.
I'm short on ideas now and even decomposing my problem to write this question didn't get me new ones
I had exactly the same problem - couldn't successfully make request on HTTP to app from Selenium-controlled browsers (Chrome or Firefox) in other Docker container on same network. cURL from that container though worked fine! Connect on HTTP, but something seemed to be trying to force HTTPS. Identical situation right down to the name of the container "app".
The answer is... it's the name of the container!
"app" is a top level domain on the HSTS preloaded list - that is, browsers will force access through HTTPS.
Fix is to use a container name that isn't on HSTS preloaded lists.
HSTS - more reading
As you mentioned manually contacting the http://app:3000 using curl inside the selenium-tester container it works as expected
This error message...
WebDriverError:Reachederrorpage:about:neterror?e=nssFailure2&u=https://app:3000/&c=UTF-8&f=regular&d=An error occurred during a connection to app:3000.
SSL received a record that exceeded the maximum permissible length.
Error code: <a id="errorCode" title="SSL_ERROR_RX_RECORD_TOO_LONG">SSL_ERROR_RX_RECORD_TOO_LONG</a>
...implies that SSL layer in curl or one of its dependencies seems broken.
#RussellFulton in this discussion mentioned:
This seems to be the result you see from Firefox when the server is not configured properly for SSL. Possibly Chrome would have just gave a generic ssl failed error.
This can happen when the browser sends a SSL handshake when the server is expecting an HTTP request. Server responds with a 400 code and an error message that is much bigger that the handshake message that the browser expects. Hence you see the message.
Reasons and Solution
When the error prone code tries to redirect to HTTPS on port 80 (port 3000 in your case).
Solution: Removing the port 80 (port 3000 in your case) from the url, the redirect works.
HTTPS by default runs over port 443.
This error also occurs when you have enabled the SSL module.
Solution: You have run a2enmod ssl.
a2enmod ssl
//or
a2ensite default-ssl
Provided a wrong IP in the ssl config.
Solution: Changed IP to what it should be.
Remove the IP if not needed in the ssl config.
Solution: Change
VirtualHost your.domain.com:443
//to
VirtualHost default:443
curl: (35) SSL received a record that exceeded the maximum permissible length. issue was discussed at length.
As per Curl Support HTTPS proxy and SOCKS+HTTP(s) there was another attempt to get the HTTPS proxy support into Curl.
This curl commit should have addressed your issue.
The following errors are being logged in our proxy Apache logs while processing the request with Tomcat Server:
(103)Software caused connection abort: proxy: pass request body failed
proxy: pass request body failed
We've a Apache reverse proxy which serves the request for the client from our Tomcat Server. Sometimes, the request from the proxy returns 502 with the above error. There are no error logs in Tomcat Server Logs correlated with the above errors in Proxy. Also, the request didn't timeout since some of the requests response time is 1 sec and our default timeout is 120 sec.
We've added ProxyBadHeader Ignore to our httpd configuration [Ref: 502 Proxy Error / Uploading from Apache (mod_proxy) to Tomcat 7] and still didn't see any errors in our Tomcat logs.
Have anyone seen this issue earlier?
We recently had this issue after upgrading one of our machines from Tomcat 6 to 7. Someone forgot to change the default apache-tomcat/conf/tomcat-users.xml file from our standard one and so the wrong password was getting checked by the server. Interestingly this results in the 502 Error you saw above. This can be avoided with some decent logging to determine it is actually an auth problem.