502 bad gateway nginx + puma + rails 3.2 on Elasti

Question

The deployment was successful and everything is green. But when we try to access the application URL, it gives 502 Bad Gateway error.

Checking for puma process with ps -aux | grep puma doesn't return any process attached to puma server but pgrep returns following.

$pgrep -fl puma
18009 su -s /bin/bash -c bundle exec puma -C /opt/elasticbeanstalk/support/conf/pumaconf.rb webapp
18031 ruby /opt/rubies/ruby-2.0.0-p598/bin/puma -C /opt/elasticbeanstalk/support/conf/pumaconf.rb

Answer 1

I had this issue after uploading my rails app, I found this line (auto generated) on secrets.yml (config > secrets.yml) :secret_key_base: <%= ENV["SECRET_KEY_BASE"] %>

so you have to add it as an environment variable to your environment.

In the environment dashboard go to Configuration > Software > Environment properties and add a new variable with name SECRET_KEY_BASE.

You can set any value but make sure it is a safe key. This resolved the issue for me, I hope it helps.

Answer 2

I have tried all possible combinations, as shown in every other forum/blog OR support sites of nginx/puma. Following is the status.

1. Default configuration - Where we have UNIX:// sock file used in the UPSTREAM option of nginx.conf and pumaconf.rb - This gives 502 bad gatway. When checked, puma is not running and it is rebooting every 3rd minute.
2. As we have used it in DigitalOcean - Change the above UPSTREAM conf URL to tcp://127.0.0.1:3000 in pumaconf.rb and 127.0.0.1:3000 in conf.d/webapp.conf file. - This is also not working, puma is not able to run properly same as above.

My question is,

1. Why there is no control over running puma with diff. configurations? And why we have to always use the UI, which is not able to run the services properly as per other standard configuration options?
2. There is no configuration options from UI, to change/verify from the UI. So we have to do it from SSH. But, we have no control over rebooting PUMA from console.
3. Whenever puma is not running, we are not able to see any logs of what error it is facing. This is really not helpful at all.

Puma is not able to run even with default configurations, so it nginx is not able to talk to Puma and so the EC2 does not really make sense!

Please let us know, how we can resolve this issue, if you have any idea on this.

See this - https://forums.aws.amazon.com/thread.jspa?messageID=608148&#608148

Still no answers on this one, this is like our hands are cuffed and not able to change any configurations!

UPDATE

AWS is somehow stopping and starting PUMA, because i can see the process IDs changing when checking with ps -ef|grep puma. So, I started the puma to work on another port and tried to check if it runs or not.

Started on another port, and then from another console accessing the URL using wget http://127.0.0.1:3000. It prints the following log.

current]$ bundle exec puma -b tcp://127.0.0.1:3001
Puma 2.0.1 starting...
* Min threads: 0, max threads: 16
* Environment: production
* Listening on tcp://127.0.0.1:3001
Rails Error: Unable to access log file. Please ensure that /var/app/current/log/production.log exists and is chmod 0666. The log level has been raised to WARN and the output directed to STDERR until the problem is fixed.
Use Ctrl-C to stop
2015-03-16 13:19:35 +0000: HTTP parse error, malformed request (): #<Puma::HttpParserError: Invalid HTTP format, parsing fails.>
2015-03-16 13:19:35 +0000: ENV: {"rack.version"=>[1, 1], "rack.errors"=>#<IO:<STDERR>>, "rack.multithread"=>true, "rack.multiprocess"=>false, "rack.run_once"=>false, "SCRIPT_NAME"=>"", "CONTENT_TYPE"=>"text/plain", "QUERY_STRING"=>"", "SERVER_PROTOCOL"=>"HTTP/1.1", "SERVER_SOFTWARE"=>"2.0.1", "GATEWAY_INTERFACE"=>"CGI/1.2"}

So, is it compulsory to use SSL? Because I think by default, it is not enabled.

Answer 3

I could not fix this problem. Also we supposed to use EC2 free instance only instead of BeanStalk.

We have now moved to Free EC2 instance with RDS and deployed the rails application using Capistrano with Nginx + Unicorn. Though it was not easy[1][2] but finally we got it working.