Je me suis retrouvé dans une situation où je déclenche manuellement une exécution de DAG Run (via airflow trigger_dag datablocks_dag), et le Dag Run apparaît dans l'interface, mais il reste alors "Running" pour toujours sans rien faire.Airflow DAG Exécuté déclenché, mais jamais exécuté?
Quand j'inspectez le DAG Exécuter dans l'interface utilisateur, je vois ce qui suit:
J'ai start_date ensemble à datetime(2016, 1, 1) et schedule_interval ensemble à @once. Mon compréhension de la lecture des docs est que depuis start_date < maintenant, le DAG sera déclenché. Le @once s'assure que cela n'arrive qu'une seule fois.
Mon fichier journal dit:
[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
ce qui pourrait être l'origine du problème?
Suis-je en train de mal comprendre comment fonctionne start_date?
Ou sont les lignes de schedule_interval inquiétantes apparentes dans le fichier journal peut-être la source du problème?
Hmm. Je cours 'airflow unpause datablocks_dag', suivi de' airflow trigger_dag datablocks_dag'. Est-ce que je les cours dans le mauvais ordre, peut-être? –
Cela devrait fonctionner correctement en théorie. Cependant, dans l'interface utilisateur, nous pouvons voir que le dag est toujours en pause. Je ne sais pas pourquoi ... Le faire manuellement devrait fonctionner. – jhnclvr
Je suis allé de l'avant et inversé l'ordre des appels, et il fonctionne maintenant comme prévu. –