I have a configured nginx sites enabled/available that when I run:
nginx -t
I get a successful test and when I:
service nginx restart
thin restart -s 1
My 502 error goes away but only for ten seconds and then it shows up again. my sites-available is:
upstream myapp {
server 0.0.0.0:3000;
}
server {
listen 80 default;
access_log /webservices/crawler/log/access.log;
error_log /webservices/crawler/error.log;
root /webservices/crawler/public/;
index index.html;
client_max_body_size 500M;
location / {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_redirect off;
if (-f $request_filename/index.html) {
rewrite (.*) $1/index.html;
break;
}
if (-f $request_filename.html) {
rewrite (.*) $1.html;
break;
}
if (!-f $request_filename) {
proxy_pass http://myapp;
break;
}
}
}
Does anyone know why my config only works for a few seconds? Thank you for any help and just let me know if you need to see any of my other code.
thin restart -s 2 output:
/# thin restart -s 2
Stopping server on 0.0.0.0:3000 ...
/usr/local/lib/ruby/gems/2.0.0/gems/thin-1.5.1/lib/thin/daemonizing.rb:131:in `send_signal': Can't stop process, no PID found in tmp/pids/thin.3000.pid (Thin::PidFileNotFound)
from /usr/local/lib/ruby/gems/2.0.0/gems/thin-1.5.1/lib/thin/daemonizing.rb:113:in `kill'
from /usr/local/lib/ruby/gems/2.0.0/gems/thin-1.5.1/lib/thin/controllers/controller.rb:93:in `block in stop'
from /usr/local/lib/ruby/gems/2.0.0/gems/thin-1.5.1/lib/thin/controllers/controller.rb:134:in `tail_log'
from /usr/local/lib/ruby/gems/2.0.0/gems/thin-1.5.1/lib/thin/controllers/controller.rb:92:in `stop'
from /usr/local/lib/ruby/gems/2.0.0/gems/thin-1.5.1/lib/thin/runner.rb:187:in `run_command'
from /usr/local/lib/ruby/gems/2.0.0/gems/thin-1.5.1/lib/thin/runner.rb:152:in `run!'
from /usr/local/lib/ruby/gems/2.0.0/gems/thin-1.5.1/bin/thin:6:in `<top (required)>'
from /usr/local/bin/thin:23:in `load'
from /usr/local/bin/thin:23:in `<main>'
Stopping server on 0.0.0.0:3001 ...
/usr/local/lib/ruby/gems/2.0.0/gems/thin-1.5.1/lib/thin/daemonizing.rb:131:in `send_signal': Can't stop process, no PID found in tmp/pids/thin.3001.pid (Thin::PidFileNotFound)
from /usr/local/lib/ruby/gems/2.0.0/gems/thin-1.5.1/lib/thin/daemonizing.rb:113:in `kill'
from /usr/local/lib/ruby/gems/2.0.0/gems/thin-1.5.1/lib/thin/controllers/controller.rb:93:in `block in stop'
from /usr/local/lib/ruby/gems/2.0.0/gems/thin-1.5.1/lib/thin/controllers/controller.rb:134:in `tail_log'
from /usr/local/lib/ruby/gems/2.0.0/gems/thin-1.5.1/lib/thin/controllers/controller.rb:92:in `stop'
from /usr/local/lib/ruby/gems/2.0.0/gems/thin-1.5.1/lib/thin/runner.rb:187:in `run_command'
from /usr/local/lib/ruby/gems/2.0.0/gems/thin-1.5.1/lib/thin/runner.rb:152:in `run!'
from /usr/local/lib/ruby/gems/2.0.0/gems/thin-1.5.1/bin/thin:6:in `<top (required)>'
from /usr/local/bin/thin:23:in `load'
from /usr/local/bin/thin:23:in `<main>'
Starting server on 0.0.0.0:3000 ...
Starting server on 0.0.0.0:3001 ...
I am pretty sure this is a Thin issue and not an nginx issue so I am posting an update. Sorry for any confusion.
my website is up for about 10 seconds and then I get the 502 nginx error. My nginx config seems fine and the nginx -t is successful. My error message is this:
thin restart -s 5
/usr/local/lib/ruby/gems/2.0.0/gems/thin-1.5.1/lib/thin/daemonizing.rb:131:in send_signal': Can't stop process, no PID found in tmp/pids/thin.3004.pid (Thin::PidFileNotFound)
from /usr/local/lib/ruby/gems/2.0.0/gems/thin-1.5.1/lib/thin/daemonizing.rb:113:inkill'
from /usr/local/lib/ruby/gems/2.0.0/gems/thin-1.5.1/lib/thin/controllers/controller.rb:93:in block in stop'
from /usr/local/lib/ruby/gems/2.0.0/gems/thin-1.5.1/lib/thin/controllers/controller.rb:134:intail_log'
from /usr/local/lib/ruby/gems/2.0.0/gems/thin-1.5.1/lib/thin/controllers/controller.rb:92:in stop'
from /usr/local/lib/ruby/gems/2.0.0/gems/thin-1.5.1/lib/thin/runner.rb:187:inrun_command'
from /usr/local/lib/ruby/gems/2.0.0/gems/thin-1.5.1/lib/thin/runner.rb:152:in run!'
from /usr/local/lib/ruby/gems/2.0.0/gems/thin-1.5.1/bin/thin:6:in'
from /usr/local/bin/thin:23:in load'
from /usr/local/bin/thin:23:in'
I have checked the PID,s and they are there. Does anyone have any idea on what is going on here? thank you and I appreciate any advice.
I found what I needed to run to clean up those thin errors. I don't know why but running:
bundle exec thin start -p 3000
fixed my situation. Thanks for everyone's help! I could not have found it without you.
Related
I am setting up VPS for the first time on upcloud. I am using unicorn 5.5.5 with Nginx. Rails 4.2.8 and ruby 2.4.2. My Nginx service runs fine. Doesn't show any error. Whenever I start unicorn service I get this error. I followed this tutorial.
https://medium.com/#manishyadavv/how-to-deploy-ruby-on-rails-apps-on-aws-ec2-7ce55bb955fa
F, [2020-06-16T12:44:20.611895 #12683] FATAL -- : error adding listener addr=/tmp/unicorn.sock
/usr/share/rvm/gems/ruby-2.4.2/gems/unicorn-5.5.5/lib/unicorn/socket_helper.rb:132:in `bind_listen': socket=/tmp/unicorn.sock specified but it is not a socket! (ArgumentError)
from /usr/share/rvm/gems/ruby-2.4.2/gems/unicorn-5.5.5/lib/unicorn/http_server.rb:243:in `listen'
from /usr/share/rvm/gems/ruby-2.4.2/gems/unicorn-5.5.5/lib/unicorn/http_server.rb:851:in `block in bind_new_listeners!'
from /usr/share/rvm/gems/ruby-2.4.2/gems/unicorn-5.5.5/lib/unicorn/http_server.rb:851:in `each'
from /usr/share/rvm/gems/ruby-2.4.2/gems/unicorn-5.5.5/lib/unicorn/http_server.rb:851:in `bind_new_listeners!'
from /usr/share/rvm/gems/ruby-2.4.2/gems/unicorn-5.5.5/lib/unicorn/http_server.rb:142:in `start'
from /usr/share/rvm/gems/ruby-2.4.2/gems/unicorn-5.5.5/bin/unicorn:128:in `<top (required)>'
from /usr/share/rvm/gems/ruby-2.4.2/bin/unicorn:23:in `load'
from /usr/share/rvm/gems/ruby-2.4.2/bin/unicorn:23:in `<main>'
from /usr/share/rvm/gems/ruby-2.4.2/bin/ruby_executable_hooks:24:in `eval'
from /usr/share/rvm/gems/ruby-2.4.2/bin/ruby_executable_hooks:24:in `<main>'
My unicorn.sock file is empty, I am sorry if this is a rookie mistake but I am stuck with this issue for 2 days now. Kindly help me out.
Here is my unicorn_repo file in the etc/init.d directory
#!/bin/sh
### BEGIN INIT INFO
# Provides: unicorn
# Required-Start: $all
# Required-Stop: $all
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: starts the unicorn app server
# Description: starts unicorn using start-stop-daemon
### END INIT INFO
set -e
USAGE="Usage: $0 <start|stop|restart|upgrade|rotate|force-stop>"
# app settings
USER="root"
APP_NAME="soup"
APP_ROOT="/$USER/$APP_NAME"
ENV="production"
# environment settings
PATH="/home/$USER/.rbenv/shims:/home/$USER/.rbenv/bin:$PATH"
CMD="cd $APP_ROOT && bundle exec unicorn -c config/unicorn.rb -E $ENV -D"
PID="$APP_ROOT/shared/pids/unicorn.pid"
OLD_PID="$PID.oldbin"
here is my nginx/default file
upstream app {
# Path to Unicorn SOCK file, as defined previously
server unix:/tmp/unicorn.sock fail_timeout=0;
}
server {
listen 0.0.0.0;
server_name localhost;
root root/soup/;
try_files $uri/index.html $uri #app;
location #app {
proxy_pass http://app;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_redirect off;
}
error_page 500 502 503 504 /500.html;
client_max_body_size 4G;
keepalive_timeout 10;
}
Here is my unicorn.rb file.
# set path to application
app_dir = File.expand_path("../..", __FILE__)
shared_dir = "#{app_dir}/shared"
working_directory app_dir
# Set unicorn options
worker_processes 2
preload_app true
timeout 30
# Set up socket location
listen "/tmp/unicorn.sock", :backlog => 64
listen 3000, :tcp_nopush => true
# Logging
stderr_path "#{shared_dir}/log/unicorn.stderr.log"
stdout_path "#{shared_dir}/log/unicorn.stdout.log"
# Set master PID location
pid "#{shared_dir}/pids/unicorn.pid"
~
~
~
~
A socket is a special kind of file used for inter process communication.
If you you run ls -la sockets have a leading s in the mode string.
Yours should look something like this:
srwxrwxrwx /tmp/unicorn.sock
If you have created /tmp/unicorn.sock as a file manually, delete it.
As a side note: The tutorial you are using is 3 years old and so your setup is outdated from the start.
Ruby 2.5.1, Rails 5.2.2.1
I'm trying to make nginx get upstream through puma socket.
When I run rails s -e production all is good.
When I run rails s -e production -d Nginx returns 502 Bad Gateway
config/puma.rb
...
app_dir = "/home/user/myapp"
tmp_dir = "#{app_dir}/tmp"
# Set up socket location
bind "unix://#{tmp_dir}/sockets/puma.sock"
# Logging
stdout_redirect "#{app_dir}/log/puma.stdout.log", "#{app_dir}/log/puma.stderr.log", true
...
etc/nginx/sites-enabled/mydomain.com
upstream app {
# Path to Puma SOCK file, as defined previously
server unix:/home/user/myapp/tmp/sockets/puma.sock fail_timeout=0;
}
server {
listen 80;
server_name mydomain.com;
root /home/user/myapp/public;
try_files $uri/index.html $uri #app;
location #app {
proxy_pass http://app;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_redirect off;
}
error_page 500 502 503 504 /500.html;
client_max_body_size 4G;
keepalive_timeout 10;
}
var/log/nginx/error.log
2019/07/07 13:45:09 [error] 21609#21609: *11391 connect() to
unix:/home/user/myapp/tmp/sockets/puma.sock failed (111: Connection
refused) while connecting to upstream, client: 172.68.11.91, server:
mydomain.com, request: "GET /pages/one HTTP/1.1", upstream:
"http://unix:/home/user/myapp/tmp/sockets/puma.sock:/pages/one", host: "mydomain.com"
(P.S. change from original domain to mydomain.com)
What difference? How to fix it? Please explain and help
UPDATE
Seems to be running with daemon flag it doesn't create puma.sock in /home/user/myapp/tmp/sockets. Why and where is it?
The earlier answer does not work any more. The deamon option -d is deprecated.
You could use a systemd service:
sudo nano /etc/systemd/system/puma.service
Copy this to the file and fill in your YOUR_APP_PATH and FULLPATH:
[Unit]
Description=Puma HTTP Server
After=network.target
# Uncomment for socket activation (see below)
# Requires=puma.socket
[Service]
# Puma supports systemd's `Type=notify` and watchdog service
# monitoring, if the [sd_notify](https://github.com/agis/ruby-sdnotify) gem is installed,
# as of Puma 5.1 or later.
# On earlier versions of Puma or JRuby, change this to `Type=simple` and remove
# the `WatchdogSec` line.
Type=notify
# If your Puma process locks up, systemd's watchdog will restart it within seconds.
WatchdogSec=10
# Preferably configure a non-privileged user
# User=
# The path to your application code root directory.
# Also replace the "<YOUR_APP_PATH>" placeholders below with this path.
# Example /home/username/myapp
WorkingDirectory=<YOUR_APP_PATH>
# Helpful for debugging socket activation, etc.
# Environment=PUMA_DEBUG=1
# SystemD will not run puma even if it is in your path. You must specify
# an absolute URL to puma. For example /usr/local/bin/puma
# Alternatively, create a binstub with `bundle binstubs puma --path ./sbin` in the WorkingDirectory
ExecStart=/<FULLPATH>/bin/puma -C <YOUR_APP_PATH>/puma.rb
# Variant: Rails start.
# ExecStart=/<FULLPATH>/bin/puma -C <YOUR_APP_PATH>/config/puma.rb ../config.ru
# Variant: Use `bundle exec --keep-file-descriptors puma` instead of binstub
# Variant: Specify directives inline.
# ExecStart=/<FULLPATH>/puma -b tcp://0.0.0.0:9292 -b ssl://0.0.0.0:9293?key=key.pem&cert=cert.pem
Restart=always
[Install]
WantedBy=multi-user.target
Run systemctl daemon-reload to reload your services.
Then you can use sudo systemctl restart puma to restart/start/stop the service
Refer to the puma docs for more information.
Solution
Dont know why, but It works if run puma (not rails server)
RAILS_ENV=production bundle exec puma -C config/puma.rb -d
Follow rails one app click deployment. Database done well, even I check rails console everything working fine.
Ruby version is 2.3.0 and rails version is 5.0.1
But when I hit IP address it gives an error time out
on check unicorn logs I get
/usr/local/rvm/gems/ruby-2.2.1/gems/unicorn-5.0.1/bin/unicorn:126:in `<top (required)>'
/usr/local/rvm/gems/ruby-2.2.1/bin/unicorn:23:in `load'
/usr/local/rvm/gems/ruby-2.2.1/bin/unicorn:23:in `<main>'
/usr/local/rvm/gems/ruby-2.2.1#global/bin/ruby_executable_hooks:15:in `eval'
/usr/local/rvm/gems/ruby-2.2.1#global/bin/ruby_executable_hooks:15:in `<main>'
E, [2017-02-26T15:47:18.969274 #9861] ERROR -- : reaped #<Process::Status: pid 11928 exit 1> worker=2
I, [2017-02-26T15:47:18.969471 #9861] INFO -- : worker=2 spawning...
I, [2017-02-26T15:47:18.974112 #11942] INFO -- : worker=2 spawned pid=11942
I, [2017-02-26T15:47:18.978540 #11936] INFO -- : Refreshing Gem list
I, [2017-02-26T15:47:18.986558 #11938] INFO -- : Refreshing Gem list
and nginx error is
017/02/26 15:34:17 [error] 18564#0: *31 connect() to unix:/var/run/unicorn.sock failed (111: Connection refused) while connecting to upstream, client: 121.52.156.57, server: _, request: "GET / HTTP/1.1", upstream: "http://unix:/var/run/unicorn.sock:/", host: "188.166.157.124"
2017/02/26 15:35:42 [error] 32360#0: *1 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 119.155.34.115, server: _, request: "GET / HTTP/1.1", upstream: "http://unix:/var/run/unicorn.sock/", host: "188.166.157.124"
2017/02/26 15:42:38 [error] 6296#0: *1 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 119.152.140.90, server: _, request: "GET / HTTP/1.1", upstream: "http://unix:/var/run/unicorn.sock/", host: "188.166.157.124"
unicorn.conf
listen "unix:/var/run/unicorn.sock"
worker_processes 4
user "rails"
working_directory "/home/rails/company_startup"
pid "/var/run/unicorn.pid"
stderr_path "/var/log/unicorn/unicorn.log"
stdout_path "/var/log/unicorn/unicorn.log"
ps aux | grep unicor
rails 4751 18.0 4.2 172880 21516 ? R 14:59 0:00 unicorn worker[2] -D -c /etc/unicorn.conf -E production
rails 4757 0.0 4.1 172404 20972 ? Rl 14:59 0:00 unicorn worker[3] -D -c /etc/unicorn.conf -E production
rails 4760 0.0 2.9 159860 14568 ? Rl 14:59 0:00 unicorn worker[1] -D -c /etc/unicorn.conf -E production
root 4764 0.0 0.1 11712 620 pts/0 S+ 14:59 0:00 grep --color=auto unicorn
root 20463 0.4 2.6 146740 13176 ? Sl 04:32 2:48 unicorn master -D -c /etc/unicorn.conf -E production
nginx file here:
upstream app_server {
server unix:/var/run/unicorn.sock fail_timeout=0;
}
server {
listen 80;
root /home/rails/company_startup/public;
server_name _;
index index.htm index.html;
client_max_body_size 1M;
location / {
try_files $uri/index.html $uri.html $uri #app;
}
location ~* ^.+\.(jpg|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|mid|midi|wav|bmp|rtf|mp3|flv|mpeg|avi)$ {
try_files $uri #app;
}
location #app {
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_redirect off;
proxy_pass http://app_server;
}
}
This sounds like an unicorn restart problem. You said you don't use capistrano. How do you deploy your application?
EDIT
Unicorn makes better use of resources available to you using multi-process architecture. When it starts, the worker loads the ruby environment and then spawns workers that handles the requests. The master never handles the request, always the workers.
When a worker takes too long, the master can kill it and starts a new worker again.
You seem to use 4 workers. I don't know the size of your droplet on DO, but it seems that the master can't start anymore workers. Could you tell me the size of your droplet (CPU & memory)?
I would install the unicorn-worker-killer gem and test the application again. This should restart your workers in a more effective way than the unicorn master.
EDIT 2:
If this doesn't work, could you try replacing your upstream line with this in your nginx conf file:
upstream app_server { server 127.0.0.1:8080 fail_timeout=0; }
And this in your unicorn conf file:
listen "127.0.0.1:8080
And restart nginx then unicorn.
EDIT 3:
I think I got it
Could you please change your files like this :
unicorn.conf
listen "/var/run/unicorn.sock"
worker_processes 4
user "rails"
working_directory "/home/rails/company_startup"
pid "/var/run/unicorn.pid"
stderr_path "/var/log/unicorn/unicorn.log"
stdout_path "/var/log/unicorn/unicorn.log"
Nginx file
upstream app_server {
server unix:/var/run/unicorn.sock fail_timeout=0;
}
server {
listen 80;
root /home/rails/company_startup/public;
server_name <PLEASE PUT YOUR SERVER NAME>;
index index.htm index.html;
client_max_body_size 1M;
location / {
try_files $uri/index.html $uri.html $uri #app;
}
location ~* ^.+\.(jpg|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|mid|midi|wav|bmp|rtf|mp3|flv|mpeg|avi)$ {
try_files $uri #app;
}
location #app {
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_redirect off;
proxy_pass http://app_server;
}
}
Restart unicorn (Make sure to replace the values between <>)
kill -s QUIT $(< /var/run/unicorn.pid)
bundle exec unicorn -c <PATH TO unicorn.conf FILE> -E <RAILS ENVIRONMENT> -D
Then restart nginx
sudo service nginx restart
and see if it works.
I am running rails app with puma, capistrano, and nginx on a google compute engine VM with ubuntu 14.04 LTS.
I have the nginx running on the external IP. And when I visit it I get two nginx errors in the log:
2016/02/03 11:58:07 [info] 19754#0: *73 client closed connection while waiting for request, client: ###.##.##.###, server: 0.0.0.0:443
2016/02/03 11:58:07 [crit] 19754#0: *74 connect() to unix:///home/my-user-name/apps/my-web-app/shared/tmp/sockets/my-web-app-puma.sock failed (13: Permission denied) while connecting to upstream, client: ###.##.##.###, server: ,
request: "GET / HTTP/1.1", upstream: "http://unix:///home/my-user-name/apps/my-web-app/shared/tmp/sockets/my-web-app-puma.sock:/", host: "###.###.###.###"
Note: the last ###.###.###.### is the external IP of the google compute VM that the code is running on. I believe the 1st two IP's are my home IP.
I have tried: setsebool httpd_can_network_connect on as suggested here:
(13: Permission denied) while connecting to upstream:[nginx]
And it returned: setsebool: SELinux is disabled. But the problem persists.
I have looked at (13: Permission denied) while connecting to upstream:[nginx] as well, but it seems to be particular to uwsgi
Here is my nginx.conf
upstream puma {
server unix:///home/my-user-name/apps/my-web-app/shared/tmp/sockets/my-web-app-puma.sock;
}
server {
listen 80 default_server deferred;
listen 443 ssl;
# server_name example.com;
ssl_certificate /etc/ssl/my-web-app/my-web-app.com.chained.crt;
ssl_certificate_key /etc/ssl/my-web-app/my-web-app.key;
root /home/my-web-app/apps/my-web-app/current/public;
access_log /home/my-user-name/apps/my-web-app/current/log/nginx.access.log;
error_log /home/my-user-name/apps/my-web-app/current/log/nginx.error.log info;
location ^~ /assets/ {
gzip_static on;
expires max;
add_header Cache-Control public;
}
try_files $uri/index.html $uri #puma;
location #puma {
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_redirect off;
proxy_pass http://puma;
}
error_page 500 502 503 504 /500.html;
client_max_body_size 10M;
keepalive_timeout 10;
}
I run nginx with sudo service nginx restart
Then I run puma with: RACK_ENV=production bundle exec puma -p 3000 and it returns:
Puma starting in single mode...
* Version 2.14.0 (ruby 2.1.7-p400), codename: Fuchsia Friday
* Min threads: 0, max threads: 16
* Environment: production
* Listening on tcp://0.0.0.0:3000
Use Ctrl-C to stop
EDIT 1
It was suggested that I run puma on unix not tcp 3000 so that it'd match nginx
I have tried running puma on unix via the command:
RACK_ENV=production bundle exec puma -d -b unix:///tmp/my-web-app.sock --pidfile /tmp/puma.pid
which gave:
Puma starting in single mode...
* Version 2.14.0 (ruby 2.1.7-p400), codename: Fuchsia Friday
* Min threads: 0, max threads: 16
* Environment: production
* Daemonizing...
It reads the above text, but it does not linger, the command prompt occurs again immediately despite the '...' at the end.
This command seemingly does not work, so if anyone can suggest how to run puma on unix and not tcp 3000, then I could complete the suggestion. (Though I suspect there is a configuring nginx issue that may be occuring before anything that has to do with puma)
EDIT 2 Attaching puma.rb
#!/usr/bin/env puma
directory '/home/my-user-name/apps/my-web-app/current'
rackup "/home/my-user-name/apps/my-web-app/current/config.ru"
environment 'production'
pidfile "/home/my-user-name/apps/my-web-app/shared/tmp/pids/puma.pid"
state_path "/home/my-user-name/apps/my-web-app/shared/tmp/pids/puma.state"
stdout_redirect '/home/my-user-name/apps/my-web-app/current/log/puma.error.log', '/home/my-user-name/apps/my-web-app/current/log/puma.access.log', true
threads 2,8
bind 'unix:///home/my-user-name/apps/my-web-app/shared/tmp/sockets/my-web-app-puma.sock'
workers 1
preload_app!
on_restart do
puts 'Refreshing Gemfile'
ENV["BUNDLE_GEMFILE"] = "/home/my-user-name/apps/my-web-app/current/Gemfile"
end
on_worker_boot do
ActiveSupport.on_load(:active_record) do
ActiveRecord::Base.establish_connection
end
end
EDIT 3
I now tried just running the rails server on port 80 directly. I typed:
rvmsudo rails server -p 80 and it returned:
=> Booting Puma
=> Rails 4.2.4 application starting in development on http://localhost:80
=> Run `rails server -h` for more startup options
=> Ctrl-C to shutdown server
Puma 2.14.0 starting...
* Min threads: 0, max threads: 16
* Environment: development
* Listening on tcp://localhost:80
Exiting
/home/my-user-name/apps/my-web-app/shared/bundle/ruby/2.1.0/gems/puma-2.14.0/lib/puma/binder.rb:233:in `initialize': Address already in use - bind(2) for "localhost" port 80 (Errno::EADDRINUSE)
from /home/my-user-name/apps/my-web-app/shared/bundle/ruby/2.1.0/gems/puma-2.14.0/lib/puma/binder.rb:233:in `new'
from /home/my-user-name/apps/my-web-app/shared/bundle/ruby/2.1.0/gems/puma-2.14.0/lib/puma/binder.rb:233:in `add_tcp_listener'
from (eval):2:in `add_tcp_listener'
from /home/my-user-name/apps/my-web-app/shared/bundle/ruby/2.1.0/gems/puma-2.14.0/lib/rack/handler/puma.rb:33:in `run'
from /home/my-user-name/apps/my-web-app/shared/bundle/ruby/2.1.0/gems/rack-1.6.4/lib/rack/server.rb:286:in `start'
from /home/my-user-name/apps/my-web-app/shared/bundle/ruby/2.1.0/gems/railties-4.2.4/lib/rails/commands/server.rb:80:in `start'
from /home/my-user-name/apps/my-web-app/shared/bundle/ruby/2.1.0/gems/railties-4.2.4/lib/rails/commands/commands_tasks.rb:80:in `block in server'
from /home/my-user-name/apps/my-web-app/shared/bundle/ruby/2.1.0/gems/railties-4.2.4/lib/rails/commands/commands_tasks.rb:75:in `tap'
from /home/my-user-name/apps/my-web-app/shared/bundle/ruby/2.1.0/gems/railties-4.2.4/lib/rails/commands/commands_tasks.rb:75:in `server'
from /home/my-user-name/apps/my-web-app/shared/bundle/ruby/2.1.0/gems/railties-4.2.4/lib/rails/commands/commands_tasks.rb:39:in `run_command!'
from /home/my-user-name/apps/my-web-app/shared/bundle/ruby/2.1.0/gems/railties-4.2.4/lib/rails/commands.rb:17:in `<top (required)>'
from bin/rails:4:in `require'
from bin/rails:4:in `<main>'
EDIT 4
If I run sudo service nginx stop then run rvmsudo rails server -p 80 again it returns:
=> Booting Puma
=> Rails 4.2.4 application starting in development on http://localhost:80
=> Run `rails server -h` for more startup options
=> Ctrl-C to shutdown server
Puma 2.14.0 starting...
* Min threads: 0, max threads: 16
* Environment: development
* Listening on tcp://localhost:80
That means that approach was incorrect since without nginx when I visit the external IP nothing its now returns The server refused the connection. as opposed to the original:
We're sorry, but something went wrong.
If you are the application owner check the logs for more information.
If anyone knows how to prevent the original error, any suggestions would be much appreciated.
EDIT 5
The original question remains, but can anyone tell me if this is an https problem or an ssl problem?
EDIT 6
I have tried running puma directly on 80 and am getting a permission error on 80.
I try: RACK_ENV=production bundle exec puma -p 80 and get:
Puma starting in single mode...
* Version 2.14.0 (ruby 2.1.7-p400), codename: Fuchsia Friday
* Min threads: 0, max threads: 16
* Environment: production
* Listening on tcp://0.0.0.0:80
/home/my-user-name/apps/my-web-app/shared/bundle/ruby/2.1.0/gems/puma-2.14.0/lib/puma/binder.rb:233:in `initialize': Permission denied - bind(2) for "0.0.0.0" port 80 (Errno::EACCES)
from /home/my-user-name/apps/my-web-app/shared/bundle/ruby/2.1.0/gems/puma-2.14.0/lib/puma/binder.rb:233:in `new'
from /home/my-user-name/apps/my-web-app/shared/bundle/ruby/2.1.0/gems/puma-2.14.0/lib/puma/binder.rb:233:in `add_tcp_listener'
from /home/my-user-name/apps/my-web-app/shared/bundle/ruby/2.1.0/gems/puma-2.14.0/lib/puma/binder.rb:98:in `block in parse'
from /home/my-user-name/apps/my-web-app/shared/bundle/ruby/2.1.0/gems/puma-2.14.0/lib/puma/binder.rb:84:in `each'
from /home/my-user-name/apps/my-web-app/shared/bundle/ruby/2.1.0/gems/puma-2.14.0/lib/puma/binder.rb:84:in `parse'
from /home/my-user-name/apps/my-web-app/shared/bundle/ruby/2.1.0/gems/puma-2.14.0/lib/puma/runner.rb:119:in `load_and_bind'
from /home/my-user-name/apps/my-web-app/shared/bundle/ruby/2.1.0/gems/puma-2.14.0/lib/puma/single.rb:79:in `run'
from /home/my-user-name/apps/my-web-app/shared/bundle/ruby/2.1.0/gems/puma-2.14.0/lib/puma/cli.rb:215:in `run'
from /home/my-user-name/apps/my-web-app/shared/bundle/ruby/2.1.0/gems/puma-2.14.0/bin/puma:10:in `<top (required)>'
from /home/my-user-name/apps/my-web-app/shared/bundle/ruby/2.1.0/bin/puma:23:in `load'
from /home/my-user-name/apps/my-web-app/shared/bundle/ruby/2.1.0/bin/puma:23:in `<main>'
I believe that this is caused because port 80 has higher permissions than others. So, I ran sudo RACK_ENV=production bundle exec puma -p 80 but that just returned: Your Ruby version is 1.9.3, but your Gemfile specified 2.1.7
I got the same error with you, I got a solution but don't know should it be right.
Change the first line of file /etc/nginx/nginx.conf
user www-data;
to
user root;
Then restart the nginx using:
service nginx restart OR systemctl restart nginx
WARNING: This runs your web server as the root user. This should never be done in a production environment as it allows the web server processes full access to your system. If the web server process is compromised, the attacker will have unrestricted access to your whole server.
Take a look at your puma.error.log file for your application.
Mine was complaining about a small syntax error in a config block on production environment.
/etc/nginx/nginx.conf looks like:
user deploy;
worker_processes 5;
error_log logs/error.log;
events {
worker_connections 1024;
use epoll;
}
http {
include mime.types;
default_type application/octet-stream;
sendfile on;
keepalive_timeout 65;
upstream foreman4000 {
server x.x.x.x:4000;
server x.x.x.x:4001;
server x.x.x.x:4002;
server x.x.x.x:4003;
server x.x.x.x:4004;
}
server {
listen 80;
server_name x.x.x.x; #server IP
access_log /opt/nginx/foreman4000.access.log;
location / {
proxy_pass http://foreman4000;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $remote_addr;
}
}
}
Here I use gem foreman, which uses upstart to manage all process and start all servers with one command
I created Procfile in the main directory of the project which contains:
redis: redis-server
thin: bundle exec thin start -p $PORT
faye: rackup faye.ru -E production -s thin
Added to Gemfile:
gem 'foreman'
gem 'thin'
gem "foreman-export-daemontools", "~> 0.0.1"
Ran bundle install locally to edit Gemfile.lock
Deployed project on the server.
Started Nginx
deploy#dcards101:/opt/nginx/conf$ sudo /etc/init.d/nginx stop [ OK ]
deploy#dcards101:/opt/nginx/conf$ sudo /etc/init.d/nginx srart [ OK ]
Exported data from Procfile to Upstart
deploy#dcards101:/var/www/cards/current$ rvmsudo foreman export upstart -a cards -u root
Started application
deploy#dcards101:/var/www/cards/current$ rvmsudo start cards
Now everything had to be good but what i see on the server is only
502 Bad Gateway
nginx/1.0.15
Logs say:
2012/07/17 17:22:30 [error] 11593#0: *148 no live upstreams while connecting to upstream, client: x.x.x.x, server: x.x.x.x, request: "GET / HTTP/1.1", upstream: "http://foreman4000/", host: "x.x.x.x"
Please help with anything you can. Server -- Ubuntu 10 LTS.
got the same error solved it this way:
first install nginx_tcp_proxy_module
( I followed this tutorial but changed it to use passenger and thin with nginx)
than add the tcp part to your nginx.conf:
tcp {
upstream websockets {
## node processes
server 12.34.56.78:9292;
check interval=300 rise=2 fall=5 timeout=1000;
}
server {
listen 9200;
server_name domain.org;
tcp_nodelay on;
proxy_pass websockets;
}
}
doesn´t work on port 80 for me
after that I still get empty responses from faye/privat_pub but there was an extremly trivial solution:
RAILS_ENV=production bundle exec rackup private_pub.ru -s thin -E production
look private_pub - Issue #29
Now everything works except chrome how fires 2 times
(and I need an deamon-process for the rackup)
hope it helps you too
I think your problem is that you put your app-server and the faye server in the same upstream!
If I get the method of upstream and foreman right, your first visitor get the app the second faye and so on. ( maybe I`m wrong because I don´t know foreman .. but if foreman shares all available servers to all services, that might be your problem )
I wood say try capistrano instead of foreman .. so you have full control which server starts where .. because at my my host http don`t work for private_pub (because of nginx) so I had to install the nginx_tcp_proxy_module to get the tcp block working in my nginx.conf
or just try server by server via ssh to find the error