502 error after AWS EC2 redash reboot

The initial idea was to try and update v8 to v10. It is recommended to create a backup so after reading this forum I found that I can create AMI of existing instance and use it as a backup. Which I did. The problem was that the instance rebooted and now I lost access to my redash as I get 502 error.

Someone suggested the following:

A simple installation on a Ec2 Server will not do that for you, you have to ask your ec2 to launch redash on startup process

But I cannot do this because I launched my initial instance from this AMI

Someone had similar issue, but the proposed solution did not work for me. I used t2.small and it worked totally fine before reboot. My inbound security is also configured properly (22 (SSH), 80 (HTTP) and 443 (HTTPS).

I have queries there, very complicated ones, this will be the second time I am loosing my entire redash (forgot my password 1st time), please help!!

P.S. Spinning the previously created AMI gives the same 502 error supposedly because redash is not launching in this case either?

If you created an AMI of a working EC2 instance running Redash then any new instance you create from it should also work as well.
Did you make an configuration changes to the previous instance in terms of the web server etc.?
Have you tried using a larger instance type then t2.small? (I notice someone on the thread you linked to had a similar issue that was resolved by using a larger instance).
How are you accessing Redash on the EC2 instance e.g. directly via an attached Public IP address, or behind a load balancer?

1 Like

Hello,

No, I did not make any configuration changes, I was able to access redash before creating AMI but afterwards I cannot access original redash, nor can I spin this AMI and get access to redash, I get 502 in both cases.

502 ERROR

The request could not be satisfied. CloudFront attempted to establish a connection with the origin, but either the attempt failed or the origin closed the connection. We can’t connect to the server for this app or website at this time. There might be too much traffic or a configuration error. Try again later, or contact the app or website owner.If you provide content to customers through CloudFront, you can find steps to troubleshoot and help prevent this error by reviewing the CloudFront documentation.

I just changed instance type to t2.xlarge but still get 502 error. I am accessing redash directly via elastic IP (which points to my subdomain). But it all worked just fine before the reboot, I had no issues.

As a general thought, that kind of behaviour could be explained by something (Docker?) not being configured to automatically start upon boot.

For a 502 error, it’s “probably” (eg I’m guessing :wink:) Nginx starting fine, but Redash inside the AMI hasn’t started.

That’d explain why your browser connects to the website, but gets an error instead of Redash.

Do you have ssh access to your instance? If so, log in and check if the Redash processes are running. :slight_smile:

This exactly.

The best option here is to ssh into the instance so you can preserve your database. If the instance is fubar you can always spin up another instance pointed at the database dump (locally or on a cloud VM somewhere) and pull your queries out of it.

I’d skip trying to access the web app and go for the back-end until the stakes aren’t so high.

Sorry to hear you’re dealing with this. Please post further details / progress if you have them.

This is too much, I liked redash, but it is super frustrating. The instance could be stopped or rebooted for a variety of reasons, it is a common thing, why there is no automatic configuration in AMI for redash to start upon reboot?

I understand your frustration but I think the target is misguided. If you are using an AMI that we provide, Redash will start automatically upon boot. You said this is an AMI that you created. So the issue here is not with our AMI or Redash in general but something about how a member of your organisation configured it.

No, I said I created AMI as a backup and in doing so, the original redash created from your AMI rebooted. Both instances, the original one and the copied one return 502.

In other words, the AMI you provided did not start redash automatically after reboot.

If you would like to dig-in to this issue further I’m happy to keep answering questions and debugging. There is nothing about our AMI’s design that causes what you are experiencing. For now it’s just a matter of either solving your problem…or not.

The next step is the same: SSH into the machine so you can see exactly what isn’t working. Very likely Redash tried to start and something failed, so it didn’t.

Would like to see this resolved anyway so you can recover your queries.

Ok, so I just tried to spin a brand new redash instance. I got it from here . The instance is running on EC2 AWS us east 2, t2 small… Its public IPv4 address is 3.139.68.235, but I get this error:

This site can’t be reached
3.139.68.235 took too long to respond.

What am I doing wrong? This is just brand new redash instance, no elastic IP. no https, no elastic load, nothing.

1 Like

Seems to be working just fine. I just visited that IP address and was displayed the option to set up the instance.

Ok, might be cache or something on my computer, I opened it on my tablet…I just rebooted it, can you open it again? I am getting 502 on this one too.

I just successfully accessed moments ago at 20:55:30 UTC.

Are you working through a proxy? Also, I’ve unlisted this thread for the moment in-case someone spots that IP address and decides to troll while you’re figuring this out.

Thanks, I just terminated that instance. Still, it does not help with my original instance…