web-dev-qa-db-ja.com

デーモンプロセスとしてのエアフロースケジューラの実行に関する問題

LocalExecutorを使用してエアフロー1.8.0を実行しているEC2インスタンスがあります。ドキュメントによると、私は次の2つのコマンドのいずれかがデーモンモードでスケジューラーを起動すると予想していました。

airflow scheduler --daemon --num_runs=20

または

airflow scheduler --daemon=True --num_runs=5

しかし、そうではありません。最初のコマンドは機能するように見えますが、バックグラウンドタスクを生成せずにターミナルに戻る前に次の出力を返すだけです。

[2017-09-28 18:15:02,794] {__init__.py:57} INFO - Using executor LocalExecutor
[2017-09-28 18:15:03,064] {driver.py:120} INFO - Generating grammar tables from /usr/lib/python3.5/lib2to3/Grammar.txt
[2017-09-28 18:15:03,203] {driver.py:120} INFO - Generating grammar tables from /usr/lib/python3.5/lib2to3/PatternGrammar.txt

2番目のコマンドはエラーを生成します。

airflow scheduler: error: argument -D/--daemon: ignored explicit argument 'True'

docs--daemon=Trueによると、airflow scheduler呼び出しの有効な引数である必要があるため、これは奇妙です。

少し掘り下げて、 このStackOverflowの投稿 に進みました。ここで、応答の1つは、使用可能なコードに従って、エアフロースケジューラをバックグラウンドプロセスとして処理するためのsystemdの実装を推奨しています。 このレポ

スクリプトの私の軽く編集された適応は、次の要点として投稿されます。 Ubuntu 16.04.3でVanilla m4.xlarge EC2インスタンスを使用しています。

そこから私は電話する:

Sudo systemctl enable airflow-scheduler
Sudo systemctl start airflow-scheduler

そして、何も起こりません。このインスタンスで実行するはるかに複雑なDAGがありますが、 このダミーケースを使用しています は、スケジューラが計画どおりに動作していることを通知するリスナーとしても機能する簡単なテストを作成します。

journalctl -fを使用してデバッグしました。スケジューラプロセスからの出力の数行はここにあります。明らかな問題はありませんが、タスクが実行されておらず、エラーを拡大するのに役立つテストDAGのログが生成されていません。ここに問題はありますか?

Sep 28 18:39:30 ip-172-31-15-209 airflow[20603]: [2017-09-28 18:39:30,965] {dag_processing.py:627} INFO - Started a process (PID: 21822) to generate tasks for /home/ubuntu/airflow/dags/scheduler_test_dag.py - logging into /home/ubuntu/airflow/logs/scheduler/2017-09-28/scheduler_test_dag.py.log
Sep 28 18:39:31 ip-172-31-15-209 airflow[20603]: [2017-09-28 18:39:31,016] {jobs.py:1002} INFO - No tasks to send to the executor
Sep 28 18:39:31 ip-172-31-15-209 airflow[20603]: [2017-09-28 18:39:31,020] {jobs.py:1440} INFO - Heartbeating the executor
Sep 28 18:39:32 ip-172-31-15-209 airflow[20603]: [2017-09-28 18:39:32,022] {jobs.py:1404} INFO - Heartbeating the process manager
Sep 28 18:39:32 ip-172-31-15-209 airflow[20603]: [2017-09-28 18:39:32,023] {jobs.py:1440} INFO - Heartbeating the executor
Sep 28 18:39:33 ip-172-31-15-209 airflow[20603]: [2017-09-28 18:39:33,024] {jobs.py:1404} INFO - Heartbeating the process manager
Sep 28 18:39:33 ip-172-31-15-209 airflow[20603]: [2017-09-28 18:39:33,025] {dag_processing.py:559} INFO - Processor for /home/ubuntu/airflow/dags/capone_dash_dag.py finished
Sep 28 18:39:33 ip-172-31-15-209 airflow[20603]: [2017-09-28 18:39:33,026] {dag_processing.py:559} INFO - Processor for /home/ubuntu/airflow/dags/scheduler_test_dag.py finished

airflow schedulerを手動で実行すると、これはすべて正常に機能します。私のテストDAGの開始日は9月9日なので、それから1分ごとにバックフィルを続け、実行時間のティッカーを作成します。ただし、systemdを使用してスケジューラをデーモンとして実行すると、エラーの明らかな原因がなく完全に静かになります。

何かご意見は?

12
Aaron

ドキュメントの日付は?

私は通常、次のようにエアフローを開始します

airflow kerberos -D
airflow scheduler -D
airflow webserver -D

airflow webeserver --help出力(バージョン1.8以降):

-D、-daemonフォアグラウンドで実行する代わりにデーモン化する

ブール値フラグは使用できないことに注意してください。ドキュメントを修正する必要があります。

ケースairflow scheduler -D失敗:

これはコメントに含まれていますが、ここで言及する価値があるようです。エアフロースケジューラを実行すると、ファイル$AIRFLOW_HOME/airflow-scheduler.pid。エアフロースケジューラデーモンプロセスを再実行しようとすると、ほぼ確実にファイル$AIRFLOW_HOME/airflow-scheduler.errこれはlockfile.AlreadyLocked: /home/ubuntu/airflow/airflow-scheduler.pid is already locked。スケジューラデーモンが実際に稼働しておらず、再起動が必要な場合は、次のコマンドを実行します。

Sudo rm $AIRFLOW_HOME airflow-scheduler.err  airflow-scheduler.pid
airflow scheduler -D 

これにより、スケジューラが軌道に乗った。

20
Tagar

Systemdによるタスク開始について:

この方法で最初に空の状態で実行すると、PATH変数に問題がありました。つまり、ファイル/ etc/sysconfig/airflowに書き込むとき:

PATH=/home/ubuntu/bin:/home/ubuntu/.local/bin:$PATH

あなたは文字通り書く:

PATH=/home/ubuntu/bin:/home/ubuntu/.local/bin

したがって、変数PATHには、LocalExecutorがタスクの実行に使用するbashユーティリティである/binが含まれていません。

したがって、このファイルでAIRFLOW_HOMEを指定していない理由はわかりません。つまり、Airflowが構成ファイルを探しているディレクトリです。

3
MSemochkin