I have installed Magneto 2 on EC2 with a MySQL database hosted separately on a RDS instance. I have configured the varnish on my EC2 server.
Whenever I open multiple tabs on the website, the varnish server crashes on a couple of product pages with the following error:
Error 503 Backend fetch failed"
Varnish version: 4.0.4 on Centos 6
I had the same problem and finally figured out what the reason was. We had the website silently running for testing without problems for a week. When we pointed our domain to the amazon EC2 instance - varnish crashed after some hours.
But that was maybe a coincidence. I found out someone was scraping the ip to find some access. logs were full of access tries to /sql /phpmyadmin /administrator ...and so on.
That caused varnish crashing.
Related
We have hosted a laravel based API backend on AWS ec2. It was working fine until this morning when suddenly the mobile app stopped working. I checked the API response on postman and it showed connect ECONNREFUSED error.
I connected to ec2 though putty and realized that the ec2 diskspace was full. I emptied the disk by deleting few project folders which made around 8% space empty. I restarted ec2 but still getting the same error
Can someone please help how to fix this?
Regards
Syed
So I rebooted an EC2 instance. When I went to pull that website up that links to that instance it is now down with a 521 error saying the website is down. We used Nginx as a web server.
I haven't tried much as I am not familiar with this issue. I do know that I should be trying to restart nginx I just do not know in what directory.
If everything was working fine for you then you can simply bring up the ngnix on ec2 machine using below command :
sudo service nginx restart
Config file for NGINX was not pointing to the correct website. I guess someone changed the file and me rebooting it enabled the changes. Just went into config file and changed the site back to the one I was using rebooted and bingo.
I am using the amazon aws e2 to host a parse server database. It was working fine for the last couple of weeks, but today I got an error 503 saying: The server is temporarily unable to service your request due to maintenance downtime or capacity problems. My question is: is it because I'm using the free t2.micro tier and I have run out of quota? Or can there be some other problem? I just launched another instance and it seems to be working fine for now.
Have you set up a load balancer? Checkout Elastic Beanstalk, which manages EC2 instances to automatically spin servers up and down as your needs require it. Your server may have just crashed and nothign was set up to automatically redeploy it.
I have EC2 instance (Redhat 7.* 64 bit) and I have installed gluu-server-3.0.1 on that ec2 instance.
I followed this tutorial to install the gluu-server on the ec2 instnce
Gluu-server installation (official)
I installed carefully following each and every step listed there on above link. Every step and command of the installation process was success (No problem with installation).
Finally when I visit the gluu-server link it redirects me to the correct link automatically. I visit http://example.com redirect me to https://example.com/identity but the gives me error 503.
Error
The server is temporarily unable to service your request due to
maintenance downtime or capacity problems. Please try again later.
If you want to post this question on the Gluu Support forum, you're more likely to get a response from the team.
Please increase ram and storage of your ec2 and try it.(If Gluu server required 4GB then go for 8GB EC2 instance and allot 6GB to Gluu server)
I have deployed tomcat 6.0.28 on two amazon ec2 instances and they share a common mysql 5.5 database. I have also made use of the elastic load balancer. When I run the program using the tomcat in my local machine, everything is fine.
But when i use the ones in EC2, i get the following error,
java.io.IOException: Server returned HTTP response code: 503 for URL:.
Can somebody help me? Thank you in advance.
Well the problem was with sessions. I did not enable stickiness. Hence the next time the load balancer routed to a different instance. I enabled stickiness in elastic load balancer and everything is fine now.