Apache、許可はmod_wsgiで拒否され、WSGISocketPrefixで修正されました-しかし、なぜですか？
ランダムに発生したように見えたサイトが今夜ダウンし、Apacheエラーログを確認した後、次の問題が発生しました。
(13)Permission denied: mod_wsgi (pid=2751): Unable to connect to WSGI daemon process 'mysite.com-ssl' on '/var/run/Apache2/wsgi.2579.0.2.sock' after multiple attempts.
今私はmod_wsgiの ConfigurationIssues wikiを読みました、そして修正は合理的であるようです。そのディレクトリに書き込むことができなかったため、WSGISocketPrefixで代替を指定する必要があります
だから私は設定しました：
WSGISocketPrefix /var/run/wsgi
それは問題を修正し、Apacheの再起動後にサイトがロードされる可能性があります。
しかし、私は非常に興味があります-なぜこのディレクトリが書き込み可能でなくなったのですか？何か不足していますか？ /var/run/Apache2ディレクトリはroot:rootが所有していますが、/var/run/wsgi*.sockで実行される新しいソケットはwww-data:rootです。サーバーの再起動がありましたが、それだけです。おそらく、何かが起動時にそのディレクトリの権限を引き継ぐでしょうか？
何か案は？ありがとう！
Apacheのグレースフルリスタートを実行し、Apacheワーカープロセスがソケット接続をまだ有効にしていて、最初のリクエストまたはキープアライブのためにその後のリクエストのためにmod_wsgiデーモンプロセスをまだ呼び出していない場合、見たエラーは一時的な問題として発生することもあります。ソケット上。
これは、グレースフルリスタート時にmod_wsgiデーモンプロセスがリスタートされ、その際にソケットファイルへのパスが大きく異なるために発生します。つまり、現在のキープアライブ要求を処理するためにぶら下がっている古いワーカープロセスは、まだソケットファイルに古いパスを使用しようとしているため、デーモンへの接続に失敗します。
ソケットファイルが置かれているディレクトリに関して重要なことは、ディレクトリがwww-dataから読み取り可能であることです。ソケットは最初にperms 0600でrootとして作成され、次に所有権をwww-dataに変更して、www-dataワーカープロセスが接続できるようにする必要があります。これは、www-dataに引き続きアクセスできるディレクトリに依存しています。
WSGISocketPrefixを使用する理由は、RedhatがApacheの設定でこのディレクトリをデフォルトとして配置するようにログディレクトリを作成し、他のユーザーが読み取れないようにして、www-dataがディレクトリ内のソケットを認識できなかったためです。これがRedhatで/ var/runに変更する必要がある理由です。
どの時点でディレクトリのアクセス許可が変更または修正されるのか、またApacheパッケージをアップグレードしないと何が発生するのかはわかりません。