nginxで(111: Connection refused）が出て、アクセスできないです。

Question

nginxがrailsサーバーに接続してません

nginxが急に接続できなくなり、We're sorry, but something went wrong.が表示されました。
現在 failed (111: Connection refused) while connecting to upstreamというエラーが発生してしまい、ウェブサイトにアクセスできなくなりました。
以下が、nignx.error.logの内容です。

 while connecting to upstream, client: 10.0.1.171, server: www.sumigokochi2020.com, request: "GET / HTTP/1.1", upstream: "http://unix:/var/www/rails/rails_app/tmp/sockets/puma.sock:/", host: "10.0.0.222"
2020/12/03 12:22:24 [error] 3277#0: *439 connect() to unix:/var/www/rails/rails_app/tmp/sockets/puma.sock failed (111: Connection refused) while connecting to upstream, client: 10.0.0.196, server: www.sumigokochi2020.com, request: "GET / HTTP/1.1", upstream: "http://unix:/var/www/rails/rails_app/tmp/sockets/puma.sock:/", host: "10.0.0.222"

rails s -e productionを実行すると以下の結果が得られます。

=> Booting Puma
=> Rails 6.0.3.4 application starting in production 
=> Run `rails server --help` for more startup options
Puma starting in single mode...
* Version 4.3.6 (ruby 2.7.2-p137), codename: Mysterious Traveller
* Min threads: 5, max threads: 5
* Environment: production
* Listening on unix:///var/www/rails/rails_app/tmp/sockets/puma.sock
Use Ctrl-C to stop

error.logの

connect() to unix:/var/www/rails/rails_app/tmp/sockets/puma.sock

とrails s -e production実行結果の

* Listening on unix:///var/www/rails/rails_app/tmp/sockets/puma.sock

のListening先とconnect先が違うことがエラーの原因なのではないかと考えているのですが、どなたかわかる人がいました、教えて頂きたいです。
railsのproduction.logが一切更新されてないので、Nginxの問題かなとは考えています。
##　本番環境

• AWS EC2 Linux
• Rails 6.0.3
• Nginx

Nginx.conffile

# For more information on configuration, see:
#   * Official English Documentation: http://nginx.org/en/docs/
#   * Official Russian Documentation: http://nginx.org/ru/docs/

user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log;
pid /run/nginx.pid;

# Load dynamic modules. See /usr/share/doc/nginx/README.dynamic.
include /usr/share/nginx/modules/*.conf;

events {
    worker_connections 1024;
}

http {
    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    sendfile            on;
    tcp_nopush          on;
    tcp_nodelay         on;
    keepalive_timeout   65;
    types_hash_max_size 4096;

    include             /etc/nginx/mime.types;
    default_type        application/octet-stream;

    # Load modular configuration files from the /etc/nginx/conf.d directory.
    # See http://nginx.org/en/docs/ngx_core_module.html#include
    # for more information.
    include /etc/nginx/conf.d/*.conf;
    # server{}欄を変更して,httpでアクセスされたものをhttpsにリダイレクトさせる
    server {
        listen       80;
        listen       [::]:80;
        server_name  www.sumigokochi2020.com;
        root         /usr/share/nginx/html;

        # Load configuration files for the default server block.
        include /etc/nginx/default.d/*.conf;

        error_page 404 /404.html;
            location = /40x.html {
        }

        error_page 500 502 503 504 /50x.html;
            location = /50x.html {
        }
    }	
}

nginx/conf.d/rails_app.conf

# log directory
error_log  /var/www/rails/rails_app/log/nginx.error.log; #自分のアプリケーション名に変更
access_log /var/www/rails/rails_app/log/nginx.access.log; #自分のアプリケーション名に変更
# max body size
client_max_body_size 2G;
upstream app_server {
  # for UNIX domain socket setups
  server unix:/var/www/rails/rails_app/tmp/sockets/puma.sock fail_timeout=0; #自分のアプリケーション名に変更
}
server {
  listen 80;
  server_name www.sumigokochi2020.com; #自分のElasticIP
  # nginx so in:creasing this is generally safe...
  keepalive_timeout 5;
  # path for static files
  root /var/www/rails/rails_app/public; #自分のアプリケーション名に変更
  # page cache loading
  try_files $uri/index.html $uri.html $uri @app;
  location @app {
    # HTTP headers
    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;
  }
  # Rails error pages
  error_page 500 502 503 504 /500.html;
  location = /500.html {
    root /var/www/rails/rails_app/public; #自分のアプリケーション名に変更
  }
}

Comments

[neko_daisuki]

We're sorry, but something went wrong は rails のエラーのはずですが
failed (111: Connection refused) while connecting to upstream となるまでの間に何か作業はされましたか？

puma.rb に pidfile '/var/www/rails/rails_app/tmp/pids/puma.pid' みたいな行があると思うのですが、
そのファイルを cat で開くと番号が書かれてます。
`ps aux | grep 番号` とすると puma 4.3.6 (unix:///var/www/rails/rails_app/tmp/sockets/puma.sock) と表示されますか？

[takayaEbino]

返信ありがとうございます。`ps aux | grep 番号` で確認したところ、
serverは`unix:///var/www/rails/rails_app/tmp/sockets/puma.sock`で、
'/etc/nginx/conf.d/rails_app.conf'のupstream_serverと違うので、修正してみたところ、無事に繋がりました。
git stashとかしたので、そこの都合でcodeが少し変形してしまい、upstream server先と、pumaの指定先がズレたのだと思います。
本当にありがとうございました。

[yu_1985]

どうでもいいですがgit stashしたらコミットしてない変更が一時退避されるのでむしろよくて、間違えて行ったのは`git push`ではないでしょうか。

[yu_1985]

あ、でもそうとも限らないか。
いずれにしても、リポジトリにあるものが正、というのが望ましい状態ですね。

[takayaEbino]

git pushが原因で今回のことが発生したことは間違いないと思います。
いくつか本番環境上で直接設定していた設定がgit pullによって吹き飛んで、errorになったんだなと感じています。
なので、開発環境にproduction用の設定を全て書き写して、mergeして、動作するようにしました。
リポジトリとはできるだけ近づけて置かないと、いらぬエラーを発生させてしまいますね。

[yu_1985]

「近づけておく」、ではなくて「リポジトリにあるものが正しい」、という状態にしてください。

[takayaEbino]

わかりました。
気をつけておきます。

Answer 1

puma.rb に pidfile '/var/www/rails/rails_app/tmp/pids/puma.pid' みたいな行があると思うのですが、

そのファイルを cat で開くと番号が書かれてます。
ps aux | grep 番号 とすると puma 4.3.6 (unix:///var/www/rails/rails_app/tmp/sockets/puma.sock) と表示されますか？

これを確かめてみたところ、
serverはunix:///var/www/rails/rails_app/tmp/sockets/puma.sockで、
/etc/nginx/conf.d/rails_app.confのupstream_server先は、

upstream app_server {
  # for UNIX domain socket setups
  server unix:/var/www/rails/rails_app/tmp/sockets/puma.sock fail_timeout=0; #自分のアプリケーション名に変更
}

でした。
rails_app.conf内のserver unix:/var/www/rails/rails_app/tmp/sockets/puma.sock と
pumaのunix:///var/www/rails/rails_app/tmp/sockets/puma.sock
が明らかにずれていたので、upstream先をpumaに合わせると無事に繋がりました。
多分本番環境で間違えて編集したものを、git stashしてしまい、その結果codeにズレが発生したのが、原因だと思います。
できる限り、本番環境では、git pullだけにしないといけないとつくづく実感しました。