web-dev-qa-db-ja.com

「sudo service nginx start」は失敗しますが、「sudo nginx」は機能します-理由がわかりません

新品に近いサーバーを使用していて、nginxが期待どおりに起動しない問題があります。基本的に同じ方法で別のサーバーを構成しましたが、そこで機能します。両者の間に環境の違いがあるに違いないと思いますが、それを見つけることができませんでした。

ショートバージョン：

Starts - Sudo nginx
Fails - Sudo service nginx start
Fails - Sudo service nginx restart
works - Sudo service nginx stop

コマンドが失敗しても、実際には何も言いません。

 * Restarting nginx nginx                                                [fail]

ログファイル（nginx [アクセスまたはエラー]、syslog）に他に何もない、または画面に書き込まれない

詳細：

どちらも設定ファイルは問題ないと言う

Sudo service nginx configtest
Sudo nginx -t

  • Nginx.confのアクセス許可を確認しましたが、それらは問題ありません（作業サーバーと同じ）www-dataがログファイルなどにアクセスできることを再確認しました。

  • /etc/init.d/nginxファイルは両方のサーバーで同じであり、使用されるコマンドも同じです（上記を参照）

  • ログファイルは存在します

  • ユーザー/グループwww-dataは存在します

  • Ubuntu 12.04 LTS

  • nginx 1.6

  • 要求を実行しました-Sudo straceサービスnginxが各サーバーで開始します以下の最初の部分を除いて、2つの異なるサーバーでの実行間で見た他の唯一の違いは、ポインターとPIDのようなものでした。私は***で異なるセットごとに2行の接頭辞を付けました

====機能するもの

clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7fd6076a09d0) = 24394
close(4)                                = 0
*** read(3, "/run/nginx.pid\n", 128)        = 15

(… snip till the bottom…)

*** rt_sigreturn(0x11)                      = 24396
dup2(11, 2)                             = 2
close(11)                               = 0
read(10, "", 8192)                      = 0
exit_group(0)                           = ?

===============失敗したもの

clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f067e79d9d0) = 21761
close(4)                                = 0
*** read(3, "/run/nginx.pid\nserver_name\n", 128) = 27

(… snip till the bottom…)

*** rt_sigreturn(0x11)                      = 21763
dup2(11, 2)                             = 2
close(11)                               = 0
read(10, "", 8192)                      = 0
exit_group(0)                           = ?
nginxubuntu-12.04upstart
6
Paul Hardwick

このような状況に遭遇したのは、そのポートがすでに別のサービスで使用されていたためです。

どうやって見つけたのですか？

実行してみてください

Sudo nginx

サービスとして開始するのではなく、エラーメッセージを表示する必要があります。

8
Mevin Babu

これは非常に満足できる、または一般的な答えにはなりませんが、私が見つけたものです。

起動メカニズムは、nginx自体が懸念していた以上の外部条件に非常に敏感なようです。

私はupstartの外でnginxを開始するための暫定的な対策があったので、サーバーの更新を続けました。現在の環境を使用していることを確認するためにnginxを再起動することになると、「Sudo service nginx restart」を使用して現在の環境を停止し、upstartスクリプトで失敗した開始コマンドを手動で入力しました失敗します）。これをしばらくして、サブドメインとファイルを他の小さなものと一緒に突然更新した後。 「Sudo service nginx restart」が機能しました。 nginxを手動で開始したり、 "Sudo service nginx restart"コマンドを実行しても、私が見つけたエラーや警告は出力されませんでした。

私が考えることができるのは、nginxではなく、upstartを悩ませたあらゆるタイプのエラーまたは警告を出すためのしきい値を下回った何らかの条件があったに違いないということです。失敗させるには十分でしたが、失敗の理由について実際のメッセージを出力するのに十分ではありませんでした。ああ！

2
Paul Hardwick

ログファイルと親ディレクトリはwww-dataが所有または読み取り可能ですか？提供するファイルとディレクトリ、および親ディレクトリはwww-dataが所有または読み取り可能ですか？

あなたはstraceを試すことができます。実行する場合：

Sudo strace service nginx start

多くの出力を生成します。最後のどこかで、おそらくアクセス許可エラーが表示されます。 straceの出力をファイルに保存し、それをgrepする方が簡単な場合があります。

もう1つのオプションは、www-dataユーザーに切り替えて、手動でログファイルの読み取り/書き込み、または提供する他のファイルの読み取り中にエラーが発生するかどうかを確認することです。 www-dataに悪いシェルがあっても、次のことができます。

Sudo su -s /bin/bash www-data

そのシェルでwhoamiを実行すると、www-dataと表示されます。

0
chicks