web-dev-qa-db-ja.com

'INFO spawnerr：不明なエラーが原因でNohupでサービスを開始できません' app_name 'のディスパッチャを作成しています：EACCES'

スーパーバイザーでサービスを開始しようとしていますが、「

INFO spawnerr： 'app_name'のディスパッチャーを作成する際の不明なエラー：EACCES

これが私のsupervisord.confファイルです：

[supervisord]
logfile=/tmp/supervisord.log
logfile_maxbytes=50MB   ; change these depending on how many logs
logfile_backups=10      ; you want to keep
loglevel=info
pidfile=/tmp/supervisord.pid
nodaemon=true
minfds=1024
minprocs=200

[rpcinterface:supervisor]
supervisor.rpcinterface_factory = supervisor.rpcinterface:make_main_rpcinterface

[supervisorctl]
serverurl=unix:///tmp/supervisor.sock  socket

[program:myscript]
command= python -u /home/ubuntu/appfolder/app_name.py
autostart=true
autorestart=unexpected 
redirect_stderr=true
stdout_logfile=/var/log/app_name.log
pythonamazon-web-servicessupervisordnohup
12
user4414636

同じ問題が発生しました。セロリサブプログラムのログがアプリフォルダーの下のログサブフォルダーに書き込まれていましたが、Nginxの問題をデバッグしているときに、所有者をwww-userに設定したことがわかりました。アプリフォルダーの所有者をubuntuに戻しました（>> whoami）

Sudo chown -R ubuntu:ubuntu /var/www/myapp/

それを機能させるために。

8
Shankar ARUL - jupyterdata.com

問題は、ログファイルのアクセス許可です。supervisorを実行しているユーザーを使用して、supervisord.confファイルと同じパスに「logs」フォルダーを作成し、以下を変更できます。

logfile=/tmp/supervisord.log

に

logfile=logs/supervisord.log
3
buzkall

私は同じ問題を抱えていました、私は以下を行うことをお勧めします

  1. サービスを実行するユーザーを追加します。 user = youruser

  2. ログをスーパーバイザーディレクトリに移動する

から：

logfile=/tmp/supervisord.log

に：

logfile=/var/log/supervisor/supervisord.log

同じことがあなたのpidファイルにも当てはまります

pidfile=/tmp/supervisord.pid >> pidfile=/var/run/supervisor/supervisord.pid

両方のdirを作る

mkdir /var/run/supervisor/

mkdir /var/log/supervisor/

次に、ディレクトリのを

chown youuser:youuser -R /var/log/supervisor/

これが機能しない場合は、誰がログファイルとpidファイルに書き込むことができるかを再確認してください。

ls -l /var/log/supervisor/supervisord.log

それでも機能しない場合は、スーパーバイザーを更新してみてください

1
Jose Pato

supervisordを非特権ユーザーとして実行しようとしたときにsupervisordを非特権ユーザー Docker コンテナーで実行すると、このエラーが発生します。[supervisord][user]ディレクティブを使用します。

これは docker＃3124 コンテナがrootとして開始され、次に別のユーザーが作成/切り替えられる（supervisordが非ルートに変更される）ことによって引き起こされます。 TTYを介したコンテナのstdin/stdout/stderrに対する制限付き権限。

私の回避策は、root以外のユーザーをttyグループに追加することです。 useradd -G tty supervisord、確認-ttyで実行していることを確認してください。 docker run ... -tまたはDockerComposetty: true。

1
javabrett

エラー情報は、アプリ「app_name」が権限のないファイルを読み書きする可能性があることを示しています。

rootで監視を開始してから、特定のユーザーに切り替えましたか？この場合、rootの所有者を使用して「app_name」にファイルを作成できますが、特定のユーザーが適切な権限を持っていない可能性があります。

0
Snriud