Airflow DAG Run ausgelöst, aber nie ausgeführt?

Question

Ich habe mich in einer Situation gefunden, in der ich manuell einen DAG Run (über airflow trigger_dag datablocks_dag) starte, und der Dag Run erscheint in der Benutzeroberfläche, aber es bleibt dann für immer "Running" ohne tatsächlich etwas zu tun.

Als ich dieses DAG Run in der Benutzeroberfläche kontrollieren, ich sehe die folgenden:

I start_date Set datetime(2016, 1, 1) und schedule_interval Set @once haben. Meine Verständnis aus dem Lesen der Dokumente ist, dass seit start_date < jetzt die DAG ausgelöst wird. Die @once stellt sicher, dass es nur ein einziges Mal passiert.

Meine Log-Datei sagt:

[2017-07-11 21:32:05,359] {jobs.py:343} DagFileProcessor0 INFO - Started process (PID=21217) to work on /home/alex/Desktop/datablocks/tests/.airflow/dags/datablocks_dag.py 
[2017-07-11 21:32:05,359] {jobs.py:534} DagFileProcessor0 ERROR - Cannot use more than 1 thread when using sqlite. Setting max_threads to 1 
[2017-07-11 21:32:05,365] {jobs.py:1525} DagFileProcessor0 INFO - Processing file /home/alex/Desktop/datablocks/tests/.airflow/dags/datablocks_dag.py for tasks to queue 
[2017-07-11 21:32:05,365] {models.py:176} DagFileProcessor0 INFO - Filling up the DagBag from /home/alex/Desktop/datablocks/tests/.airflow/dags/datablocks_dag.py 
[2017-07-11 21:32:05,703] {models.py:2048} DagFileProcessor0 WARNING - schedule_interval is used for <Task(BashOperator): foo>, though it has been deprecated as a task parameter, you need to specify it as a DAG parameter instead 
[2017-07-11 21:32:05,703] {models.py:2048} DagFileProcessor0 WARNING - schedule_interval is used for <Task(BashOperator): foo2>, though it has been deprecated as a task parameter, you need to specify it as a DAG parameter instead 
[2017-07-11 21:32:05,704] {jobs.py:1539} DagFileProcessor0 INFO - DAG(s) dict_keys(['example_branch_dop_operator_v3', 'latest_only', 'tutorial', 'example_http_operator', 'example_python_operator', 'example_bash_operator', 'example_branch_operator', 'example_trigger_target_dag', 'example_short_circuit_operator', 'example_passing_params_via_test_command', 'test_utils', 'example_subdag_operator', 'example_subdag_operator.section-1', 'example_subdag_operator.section-2', 'example_skip_dag', 'example_xcom', 'example_trigger_controller_dag', 'latest_only_with_trigger', 'datablocks_dag']) retrieved from /home/alex/Desktop/datablocks/tests/.airflow/dags/datablocks_dag.py 
[2017-07-11 21:32:07,083] {models.py:3529} DagFileProcessor0 INFO - Creating ORM DAG for datablocks_dag 
[2017-07-11 21:32:07,234] {models.py:331} DagFileProcessor0 INFO - Finding 'running' jobs without a recent heartbeat 
[2017-07-11 21:32:07,234] {models.py:337} DagFileProcessor0 INFO - Failing jobs without heartbeat after 2017-07-11 21:27:07.234388 
[2017-07-11 21:32:07,240] {jobs.py:351} DagFileProcessor0 INFO - Processing /home/alex/Desktop/datablocks/tests/.airflow/dags/datablocks_dag.py took 1.881 seconds 

Was das Problem verursacht sein könnte?

Bin ich falsch verstanden, wie start_date arbeitet?

Oder sind die besorgniserregenden schedule_intervalWARNING Zeilen in der Protokolldatei möglicherweise die Ursache des Problems?

Answer 1

Das Problem ist, dass die dag pausiert ist.

In dem Screenshot, den Sie zur Verfügung gestellt haben, in der oberen linken Ecke, spiegeln Sie dies auf On und das sollte es tun.

Dies ist ein gewöhnliches "Gotcha", wenn mit dem Luftstrom begonnen wird.