aws nginx + unicorn (13:permission dnined) while connecting to upstream でハマッた時に試したことのTIPS
aws nginx + unicorn (13:permission dnined) while connecting to upstream でハマッた時に試したことのTIPS
nginx + unicorn
下記、記事を aws のサーバーにあげた時のお話。
Rubyで仮面ライダークウガのグロンギ語翻訳ロジックを書いてみた-part1-
unicorn に接続しようとしても
nginx のログにエラーログが出力されて、一向に unicorn との連携ができなかった。
前提
nginx からの、リバースプロキシで unicorn に接続。
サーバーを勉強始めて6ヶ月目(？)くらい
unicorn の port にするつもりの3000番は、
aws の EC2 インスタンスから開放済み(ネタバレ：今回の落とし穴)
諸々の設定を終えて、unicornの立ち上げ！！
bundle exec unicorn -c config/unicorn.rb -D
あれ？繋がらないぞー。エラー・・・
*11 connect() to unix:/home/centos/unicorn/tmp/unicorn.sock failed (13: Permission denied) while connecting to upstream
さぁ、検索を始めよう・・・(仮面ライダーWてきな
確認したこと・試したこと
unicorn.sockのパーミッションは正しいか？
パーミッションがないって言われたら、まず対象のファイルのパーミッションを調べたくなりますよね。
というわけで、本能に従って調べました。
パーミッションは777で指定してあったので問題なし。
srwxrwxrwx. 1 centos centos 0 1月 10 14:33 unicorn.sock
うーん。。。じゃあどこで駄目なんだろうか。調査続行。
nginxを立ち上げたユーザーと、unicornを立ち上げたユーザーが一致しているか？
nginx を立ち上げるユーザーと、 unicorn を立ち上げたユーザーが一致しないと同じく permission denined で弾かれるそうです。
注意するポイントは、nginx はデフォルトだと nginx というユーザーになるということ。
ユーザーがあっているかを確認する時は、以下コマンドです。
[centos@ip-10-0-0-67 tmp]$ ps aux | grep nginx
nginx 6984 0.0 0.0 112660 956 pts/0 R+ 10:20 0:00 grep --color=auto nginx
root 13688 0.0 0.1 48668 1392 ? Ss 1月10 0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
nginx 13689 0.0 0.3 51304 4032 ? S 1月10 0:00 nginx: worker process
[centos@ip-10-0-0-67 tmp]$ ps aux | grep unicorn
centos 6986 0.0 0.0 112660 960 pts/0 R+ 10:21 0:00 grep --color=auto unicorn
centos 14733 0.0 2.3 218344 24220 ? Sl 1月10 0:00 unicorn master config.ru -c config/unicorn.rb -D -p 3000
centos 14736 0.0 8.2 301024 83880 ? Sl 1月10 0:02 unicorn worker[0] config.ru -c config/unicorn.rb -D -p 3000
centos 14738 0.0 8.0 299012 81788 ? Sl 1月10 0:02 unicorn worker[1] config.ru -c config/unicorn.rb -D -p 3000
確認した結果、案の定 nginx は nginx。unicorn は centos で立ち上がっていたとさorz
nginx のユーザー指定は、下記ファイルで行います。
/etc/nginx/nginx.conf
#user nginx; # 初期設定
user centos; # unicorn側のユーザーに合わせる
worker_processes 1;
error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;
・
・
・
再起動
sudo service nginx restart
[centos@ip-10-0-0-67 tmp]$ ps aux | grep nginx
centos 6984 0.0 0.0 112660 956 pts/0 R+ 10:20 0:00 grep --color=auto nginx
root 13688 0.0 0.1 48668 1392 ? Ss 1月10 0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
centos 13689 0.0 0.3 51304 4032 ? S 1月10 0:00 nginx: worker process
無事にユーザーは一致しました。
ただ、これだけだと駄目だった。他にも原因があるっぽい。
うーん。。。じゃあどこで駄目なんだろうか。調査続行(2回目)
awsのEC2のポートは空いているか？
はっ！！これか！！？
・・・というのも、最初から調査段階でハマルと知っていたので、対応していたのですけどね。
unicorn の port を3000で繋ぎたかったため、
aws の EC2 インスタンスの3000番を接続できるように開ける必要あり。
再度、確認してみたのですが3000は空いている・・・
うーん。。。じゃあどこで駄目なん(ry
unicorn起動時のportの指定は大丈夫か？
unicorn を立ち上げるコマンド実行時に、aws で開けていたポートに -port で指定していなかった。
unicorn のデフォルト port は8080（らしい）。
上記で3000を指定して開けていたので、unicorn起動時にポートを指定してあげる必要あり。
bundle exec unicorn の時に -p で port 番号を指定してあげて無事に解決。立ち上がりました。
bundle exec unicorn config.ru -c config/unicorn.rb -D -p 3000
おまけ
bundle exec unicorn config.ru -c config/unicorn.rb -D -p 3000
-c 設定ファイルの指定
-D デーモン化の指定
-p ポート番号の指定（今回の立役者）
まとめ
サーバー、ハマッた。
噂どおり、サーバーはハマると余裕で一日中使いますね・・・
合宿中にハマッたのですが、朝の8:00から15:00まで戦っていました。
今回、ハマれたし、TIPSも貯められたのでよしとしよう。
Author And Source
この問題について(aws nginx + unicorn (13:permission dnined) while connecting to upstream でハマッた時に試したことのTIPS), 我々は、より多くの情報をここで見つけました https://qiita.com/UltraBirdTech/items/4f1a4a490cfc19298ad0著者帰属：元の著者の情報は、元のURLに含まれています。著作権は原作者に属する。
Content is automatically searched and collected through network algorithms . If there is a violation . Please contact us . We will adjust (correct author information ,or delete content ) as soon as possible .