私はsystemdを使ってこのLaravel設定を作成しました。すべてを理解し、すべてをテストするのに問題があります。
理論的には、「キュー」と「スケジュール」プロセスが同時に実行された場合、両方とも「artisan」プログラムを同時に使用するため、エラーが発生しますか?
それとも、nohupプログラムは両方のプロセスを同時に実行し、プロセスをキャンセルしませんか?
今、この設定は競合しないようです。
文書.ebextensions/01_files.config
files:
"/etc/systemd/system/[email protected]":
mode: "000644"
owner: root
group: root
content: |
[Unit]
Description=Laravel %i worker
After=network.target
[Service]
User=webapp
Group=webapp
EnvironmentFile=/opt/elasticbeanstalk/deployment/env
WorkingDirectory=/var/app/current/
ExecStart=/usr/bin/nohup /usr/bin/php artisan %i:work
Restart=on-failure
文書.ebextensions/02_commands.config
commands:
01_setvars:
command: /opt/elasticbeanstalk/bin/get-config environment | jq -r 'to_entries | .[] | "export \(.key)=\"\(.value)\""' > /etc/profile.d/sh.local
02_reload_daemon:
command: systemctl daemon-reload
ignoreErrors: true
packages:
yum:
jq: []
container_commands:
01_laravel_worker_queue:
command: systemctl enable [email protected] && systemctl restart laravel_worker@queue
leader_only: true
02_laravel_worker_schedule:
command: systemctl enable [email protected] && systemctl restart laravel_worker@schedule
leader_only: true
答え1
systemd
との場合、プログラムnohup
ではなくartisan
プログラムのパラメータです/usr/bin/php
。
nohup
他のプログラムやプロセスには興味がありません。必要に応じて、同じプログラムの複数のインスタンスを起動できない理由はありません。
同じプログラムの複数のインスタンス(オプションで異なるパラメータを使用)を実行することは、まさにあなたのようなシステムサービステンプレートが設計された[email protected]
目的です。
nohup
しかし、systemdサービスで起動するときになぜ使用するのかわかりません。/usr/bin/php artisan ...
(ユーザーサービスではなく)システムサービスで構成されているため、systemdはセッションから完全に独立して開始を担当するため、ログアウト時にSIGHUPを受信するリスクはありません。
サービステンプレートにStandardOutput=
またはオプションを指定していないため、両方のインスタンスのStandardError=
標準出力と標準エラー出力はに設定されているデフォルトの出力位置に移動するか、systemd-system.conf
存在しない場合は工場出荷時のデフォルトターゲットStandardOutput=journal
に移動しますStandardError=journal
。したがって、標準出力は端末ではないため、出力が意図したとおりnohup
にリダイレクトされないことがありますphp
。/var/app/current/nohup.out
したがって、nohup
出力とすべてのエラーは、それぞれの有無に関係なく表示されるログに記録する必要があります。journalctl -u [email protected]
journalctl -u [email protected]