2017-07-12 29 views
5

मैंने खुद को एक ऐसी स्थिति में पाया है जहां मैं मैन्युअल रूप से एक डीएजी रन (airflow trigger_dag datablocks_dag के माध्यम से) चलाता हूं, और डैग रन इंटरफ़ेस में दिखाई देता है, लेकिन फिर यह वास्तव में कुछ भी किए बिना हमेशा "चल रहा है" रहता है।एयरफ्लो डीएजी रन ट्रिगर हुआ, लेकिन कभी निष्पादित नहीं हुआ?

enter image description here

मैं datetime(2016, 1, 1) को start_date सेट, और @once को schedule_interval सेट मिल गया है:

जब मैं UI में इस DAG रन का निरीक्षण किया, मैं निम्न देखें। मेरे दस्तावेज़ पढ़ने से समझना यह है कि start_date < से अब, डीएजी ट्रिगर हो जाएगा। @once सुनिश्चित करता है कि यह केवल एक ही समय होता है।

मेरे लॉग फ़ाइल का कहना है:

[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 

क्या समस्या पैदा कर हो सकता है?

क्या मुझे गलतफहमी है कि start_date कैसे संचालित होता है?

या चिंतित दिखने वाले schedule_intervalWARNING लॉग फ़ाइल में लाइनें संभवतः समस्या का स्रोत हैं?

उत्तर

3

समस्या यह है कि डैग रोका गया है।

आपके द्वारा प्रदान किए गए स्क्रीनशॉट में, शीर्ष बाएं कोने में, इसे On पर फ़्लिप करें और इसे करना चाहिए।

एयरफ्लो से शुरू होने पर यह एक आम "गोचाचा" है।

+0

हम्म। मैं 'airflow unpause datablocks_dag' चला रहा हूं, इसके बाद' airflow trigger_dag datablocks_dag' चला रहा है। क्या मैं उन्हें गलत क्रम में चला रहा हूं, शायद? –

+0

यह सिद्धांत में ठीक काम करना चाहिए। हालांकि, यूआई में हम देख सकते हैं कि डैग अभी भी रोका गया है। निश्चित नहीं है कि क्यों ... इसे मैन्युअल रूप से रोकना काम करना चाहिए। – jhnclvr

+1

मैं आगे बढ़ गया हूं और कॉल के आदेश को उलट दिया है, और अब यह अपेक्षा के अनुसार काम करता है। –

संबंधित मुद्दे