Running Airflow Tasks In Parallel - Nothing Gets Scheduled - python-3.x
I just went through the process of configuring my Airflow setup to be capable of parallel processing by following this article and using this article.
Everything seems to be working fine in the sense that I was able to run all of those commands from the articles without any errors, warnings, or exceptions. I was able to start up the airflow webserver and airflow scheduler and I'm able to go on the UI and view all my DAGs but now none of my DAGs are starting that previously were working. I had this basic example DAG that was working when my executor was set to SequentialExecuter but now that I have it set to LocalExecuter it never runs. All of the tasks in the DAG are colored white on the graph view with no status when the first one should be in the running state while it waits for the S3 file to appear. I've already cleared all of it's PAST, FUTURE, UPSTREAM history on the UI and I have the DAG turned on so that's not the issue. Also, the scheduler is currently running too.
I've tried using this Stackoverflow Post on the same topic as well but to no avail.
Here is the code I have:
from airflow import DAG
from airflow.operators import SimpleHttpOperator, HttpSensor, EmailOperator, S3KeySensor
from datetime import datetime, timedelta
from airflow.operators.bash_operator import BashOperator
default_args = {
'owner': 'airflow',
'depends_on_past': False,
'start_date': datetime(2018, 5, 29),
'email': ['something#here.com'],
'email_on_failure': False,
'email_on_retry': False,
'retries': 5,
'retry_delay': timedelta(minutes=5)
}
dag = DAG('myDag', default_args=default_args, schedule_interval= '#once')
t1 = BashOperator(
task_id='my_t1_id',
bash_command='echo "Dag Ran Successfully!" >> /home/ec2-user/output.txt',
dag=dag)
sensor = S3KeySensor(
task_id='my_sensor_id',
bucket_key='*',
wildcard_match=True,
bucket_name='foobar',
s3_conn_id='s3://foobar',
timeout=18*60*60,
poke_interval=120,
dag=dag)
t1.set_upstream(sensor)
And if needed here is my airflow.cfg file (note the only lines I changed were executor = LocalExecutor and sql_alchemy_conn = postgresql+psycopg2://postgres:password#localhost/airflow_meta_db
[core]
# The home folder for airflow, default is ~/airflow
airflow_home = /home/ec2-user/airflow
# The folder where your airflow pipelines live, most likely a
# subfolder in a code repository
# This path must be absolute
dags_folder = /home/ec2-user/airflow/dags
# The folder where airflow should store its log files
# This path must be absolute
base_log_folder = /home/ec2-user/airflow/logs
# Airflow can store logs remotely in AWS S3 or Google Cloud Storage. Users
# must supply an Airflow connection id that provides access to the storage
# location.
remote_log_conn_id =
encrypt_s3_logs = False
# Logging level
logging_level = INFO
# Logging class
# Specify the class that will specify the logging configuration
# This class has to be on the python classpath
# logging_config_class = my.path.default_local_settings.LOGGING_CONFIG
logging_config_class =
# Log format
log_format = [%%(asctime)s] {%%(filename)s:%%(lineno)d} %%(levelname)s - %%(message)s
simple_log_format = %%(asctime)s %%(levelname)s - %%(message)s
# The executor class that airflow should use. Choices include
# SequentialExecutor, LocalExecutor, CeleryExecutor, DaskExecutor
#executor = SequentialExecutor
executor = LocalExecutor
# The SqlAlchemy connection string to the metadata database.
# SqlAlchemy supports many different database engine, more information
# their website
#sql_alchemy_conn = sqlite:////home/ec2-user/airflow/airflow.db
sql_alchemy_conn = postgresql+psycopg2://postgres:password#localhost/airflow_meta_db
# The SqlAlchemy pool size is the maximum number of database connections
# in the pool.
sql_alchemy_pool_size = 5
# The SqlAlchemy pool recycle is the number of seconds a connection
# can be idle in the pool before it is invalidated. This config does
# not apply to sqlite.
sql_alchemy_pool_recycle = 3600
# The amount of parallelism as a setting to the executor. This defines
# the max number of task instances that should run simultaneously
# on this airflow installation
parallelism = 32
# The number of task instances allowed to run concurrently by the scheduler
dag_concurrency = 16
# Are DAGs paused by default at creation
dags_are_paused_at_creation = True
# When not using pools, tasks are run in the "default pool",
# whose size is guided by this config element
non_pooled_task_slot_count = 128
# The maximum number of active DAG runs per DAG
max_active_runs_per_dag = 16
# Whether to load the examples that ship with Airflow. It's good to
# get started, but you probably want to set this to False in a production
# environment
load_examples = True
# Where your Airflow plugins are stored
plugins_folder = /home/ec2-user/airflow/plugins
# Secret key to save connection passwords in the db
fernet_key = ibwZ5uSASmZGphBmwdJ4BIhd1-5WZXMTTgMF9u1_dGM=
# Whether to disable pickling dags
donot_pickle = False
# How long before timing out a python file import while filling the DagBag
dagbag_import_timeout = 30
# The class to use for running task instances in a subprocess
task_runner = BashTaskRunner
# If set, tasks without a `run_as_user` argument will be run with this user
# Can be used to de-elevate a sudo user running Airflow when executing tasks
default_impersonation =
# What security module to use (for example kerberos):
security =
# Turn unit test mode on (overwrites many configuration options with test
# values at runtime)
unit_test_mode = False
# Name of handler to read task instance logs.
# Default to use file task handler.
task_log_reader = file.task
# Whether to enable pickling for xcom (note that this is insecure and allows for
# RCE exploits). This will be deprecated in Airflow 2.0 (be forced to False).
enable_xcom_pickling = True
# When a task is killed forcefully, this is the amount of time in seconds that
# it has to cleanup after it is sent a SIGTERM, before it is SIGKILLED
killed_task_cleanup_time = 60
[cli]
# In what way should the cli access the API. The LocalClient will use the
# database directly, while the json_client will use the api running on the
# webserver
api_client = airflow.api.client.local_client
endpoint_url = http://localhost:8080
[api]
# How to authenticate users of the API
auth_backend = airflow.api.auth.backend.default
[operators]
# The default owner assigned to each new operator, unless
# provided explicitly or passed via `default_args`
default_owner = Airflow
default_cpus = 1
default_ram = 512
default_disk = 512
default_gpus = 0
[webserver]
# The base url of your website as airflow cannot guess what domain or
# cname you are using. This is used in automated emails that
# airflow sends to point links to the right web server
base_url = http://localhost:8080
# The ip specified when starting the web server
web_server_host = 0.0.0.0
# The port on which to run the web server
web_server_port = 8080
# Paths to the SSL certificate and key for the web server. When both are
# provided SSL will be enabled. This does not change the web server port.
web_server_ssl_cert =
web_server_ssl_key =
# Number of seconds the gunicorn webserver waits before timing out on a worker
web_server_worker_timeout = 120
# Number of workers to refresh at a time. When set to 0, worker refresh is
# disabled. When nonzero, airflow periodically refreshes webserver workers by
# bringing up new ones and killing old ones.
worker_refresh_batch_size = 1
# Number of seconds to wait before refreshing a batch of workers.
worker_refresh_interval = 30
# Secret key used to run your flask app
secret_key = temporary_key
# Number of workers to run the Gunicorn web server
workers = 4
# The worker class gunicorn should use. Choices include
# sync (default), eventlet, gevent
worker_class = sync
# Log files for the gunicorn webserver. '-' means log to stderr.
access_logfile = -
error_logfile = -
# Expose the configuration file in the web server
expose_config = False
# Set to true to turn on authentication:
# http://pythonhosted.org/airflow/security.html#web-authentication
authenticate = False
# Filter the list of dags by owner name (requires authentication to be enabled)
filter_by_owner = False
# Filtering mode. Choices include user (default) and ldapgroup.
# Ldap group filtering requires using the ldap backend
#
# Note that the ldap server needs the "memberOf" overlay to be set up
# in order to user the ldapgroup mode.
owner_mode = user
# Default DAG view. Valid values are:
# tree, graph, duration, gantt, landing_times
dag_default_view = tree
# Default DAG orientation. Valid values are:
# LR (Left->Right), TB (Top->Bottom), RL (Right->Left), BT (Bottom->Top)
dag_orientation = LR
# Puts the webserver in demonstration mode; blurs the names of Operators for
# privacy.
demo_mode = False
# The amount of time (in secs) webserver will wait for initial handshake
# while fetching logs from other worker machine
log_fetch_timeout_sec = 5
# By default, the webserver shows paused DAGs. Flip this to hide paused
# DAGs by default
hide_paused_dags_by_default = False
# Consistent page size across all listing views in the UI
page_size = 100
[email]
email_backend = airflow.utils.email.send_email_smtp
[smtp]
# If you want airflow to send emails on retries, failure, and you want to use
# the airflow.utils.email.send_email_smtp function, you have to configure an
# smtp server here
smtp_host = localhost
smtp_starttls = True
smtp_ssl = False
# Uncomment and set the user/pass settings if you want to use SMTP AUTH
# smtp_user = airflow
# smtp_password = airflow
smtp_port = 25
smtp_mail_from = airflow#example.com
[celery]
# This section only applies if you are using the CeleryExecutor in
# [core] section above
# The app name that will be used by celery
celery_app_name = airflow.executors.celery_executor
# The concurrency that will be used when starting workers with the
# "airflow worker" command. This defines the number of task instances that
# a worker will take, so size up your workers based on the resources on
# your worker box and the nature of your tasks
celeryd_concurrency = 16
# When you start an airflow worker, airflow starts a tiny web server
# subprocess to serve the workers local log files to the airflow main
# web server, who then builds pages and sends them to users. This defines
# the port on which the logs are served. It needs to be unused, and open
# visible from the main web server to connect into the workers.
worker_log_server_port = 8793
# The Celery broker URL. Celery supports RabbitMQ, Redis and experimentally
# a sqlalchemy database. Refer to the Celery documentation for more
# information.
broker_url = sqla+mysql://airflow:airflow#localhost:3306/airflow
# Another key Celery setting
celery_result_backend = db+mysql://airflow:airflow#localhost:3306/airflow
# Celery Flower is a sweet UI for Celery. Airflow has a shortcut to start
# it `airflow flower`. This defines the IP that Celery Flower runs on
flower_host = 0.0.0.0
# This defines the port that Celery Flower runs on
flower_port = 5555
# Default queue that tasks get assigned to and that worker listen on.
default_queue = default
# Import path for celery configuration options
celery_config_options = airflow.config_templates.default_celery.DEFAULT_CELERY_CONFIG
[dask]
# This section only applies if you are using the DaskExecutor in
# [core] section above
# The IP address and port of the Dask cluster's scheduler.
cluster_address = 127.0.0.1:8786
[scheduler]
# Task instances listen for external kill signal (when you clear tasks
# from the CLI or the UI), this defines the frequency at which they should
# listen (in seconds).
job_heartbeat_sec = 5
# The scheduler constantly tries to trigger new tasks (look at the
# scheduler section in the docs for more information). This defines
# how often the scheduler should run (in seconds).
scheduler_heartbeat_sec = 5
# after how much time should the scheduler terminate in seconds
# -1 indicates to run continuously (see also num_runs)
run_duration = -1
# after how much time a new DAGs should be picked up from the filesystem
min_file_process_interval = 0
dag_dir_list_interval = 300
# How often should stats be printed to the logs
print_stats_interval = 30
child_process_log_directory = /home/ec2-user/airflow/logs/scheduler
# Local task jobs periodically heartbeat to the DB. If the job has
# not heartbeat in this many seconds, the scheduler will mark the
# associated task instance as failed and will re-schedule the task.
scheduler_zombie_task_threshold = 300
# Turn off scheduler catchup by setting this to False.
# Default behavior is unchanged and
# Command Line Backfills still work, but the scheduler
# will not do scheduler catchup if this is False,
# however it can be set on a per DAG basis in the
# DAG definition (catchup)
catchup_by_default = True
# This changes the batch size of queries in the scheduling main loop.
# This depends on query length limits and how long you are willing to hold locks.
# 0 for no limit
max_tis_per_query = 0
# Statsd (https://github.com/etsy/statsd) integration settings
statsd_on = False
statsd_host = localhost
statsd_port = 8125
statsd_prefix = airflow
# The scheduler can run multiple threads in parallel to schedule dags.
# This defines how many threads will run.
max_threads = 2
authenticate = False
[ldap]
# set this to ldaps://<your.ldap.server>:<port>
uri =
user_filter = objectClass=*
user_name_attr = uid
group_member_attr = memberOf
superuser_filter =
data_profiler_filter =
bind_user = cn=Manager,dc=example,dc=com
bind_password = insecure
basedn = dc=example,dc=com
cacert = /etc/ca/ldap_ca.crt
search_scope = LEVEL
[mesos]
# Mesos master address which MesosExecutor will connect to.
master = localhost:5050
# The framework name which Airflow scheduler will register itself as on mesos
framework_name = Airflow
# Number of cpu cores required for running one task instance using
# 'airflow run <dag_id> <task_id> <execution_date> --local -p <pickle_id>'
# command on a mesos slave
task_cpu = 1
# Memory in MB required for running one task instance using
# 'airflow run <dag_id> <task_id> <execution_date> --local -p <pickle_id>'
# command on a mesos slave
task_memory = 256
# Enable framework checkpointing for mesos
# See http://mesos.apache.org/documentation/latest/slave-recovery/
checkpoint = False
# Failover timeout in milliseconds.
# When checkpointing is enabled and this option is set, Mesos waits
# until the configured timeout for
# the MesosExecutor framework to re-register after a failover. Mesos
# shuts down running tasks if the
# MesosExecutor framework fails to re-register within this timeframe.
# failover_timeout = 604800
# Enable framework authentication for mesos
# See http://mesos.apache.org/documentation/latest/configuration/
authenticate = False
# Mesos credentials, if authentication is enabled
# default_principal = admin
# default_secret = admin
[kerberos]
ccache = /tmp/airflow_krb5_ccache
# gets augmented with fqdn
principal = airflow
reinit_frequency = 3600
kinit_path = kinit
keytab = airflow.keytab
[github_enterprise]
api_rev = v3
[admin]
# UI to hide sensitive variable fields when set to True
hide_sensitive_variable_fields = False
airflow scheduler output:
[2018-05-31 21:15:12,056] {jobs.py:1504} INFO -
================================================================================
DAG File Processing Stats
File Path PID Runtime Last Runtime Last Run
-------------------------------------------------------------- ----- --------- -------------- -------------------
/home/ec2-user/airflow/dags/Test_Dag_Create_EMR.py 1.00s 2018-05-31T21:15:12
/home/ec2-user/airflow/dags/s3_triggered_emr_cluster_dag.py 19214 0.01s 1.00s 2018-05-31T21:15:10
/home/ec2-user/airflow/dags/myDag.py 1.00s 2018-05-31T21:15:11
/home/ec2-user/airflow/dags/s3_sensor_connection_test.py 1.01s 2018-05-31T21:15:11
/home/ec2-user/airflow/dags/three_s3_triggers_then_emr_work.py 19213 0.01s 1.01s 2018-05-31T21:15:10
================================================================================
[2018-05-31 21:15:12,112] {jobs.py:1742} INFO - Processing file /home/ec2-user/airflow/dags/three_s3_triggers_then_emr_work.py for tasks to queue
[2018-05-31 21:15:12,112] {models.py:189} INFO - Filling up the DagBag from /home/ec2-user/airflow/dags/three_s3_triggers_then_emr_work.py
[2018-05-31 21:15:12,118] {jobs.py:1742} INFO - Processing file /home/ec2-user/airflow/dags/s3_triggered_emr_cluster_dag.py for tasks to queue
[2018-05-31 21:15:12,118] {models.py:189} INFO - Filling up the DagBag from /home/ec2-user/airflow/dags/s3_triggered_emr_cluster_dag.py
[2018-05-31 21:15:12,173] {jobs.py:1754} INFO - DAG(s) dict_keys(['example_trigger_controller_dag', 'example_python_operator', 'example_skip_dag', 'test_utils', 'example_xcom', 'example_passing_params_via_test_command', 'latest_only', 'example_trigger_target_dag', 'example_branch_operator', 'example_http_operator', 'example_branch_dop_operator_v3', 'example_subdag_operator', 'example_subdag_operator.section-1', 'example_subdag_operator.section-2', 'latest_only_with_trigger', 'example_bash_operator', 'tutorial', 'example_short_circuit_operator', 's3_triggered_emr_cluster_dag']) retrieved from /home/ec2-user/airflow/dags/s3_triggered_emr_cluster_dag.py
[2018-05-31 21:15:12,173] {jobs.py:1754} INFO - DAG(s) dict_keys(['example_trigger_controller_dag', 'example_python_operator', 'example_skip_dag', 'test_utils', 'example_xcom', 'example_passing_params_via_test_command', 'latest_only', 'example_trigger_target_dag', 'example_branch_operator', 'example_http_operator', 'example_branch_dop_operator_v3', 'example_subdag_operator', 'example_subdag_operator.section-1', 'example_subdag_operator.section-2', 'latest_only_with_trigger', 'example_bash_operator', 'tutorial', 'example_short_circuit_operator', 'three_s3_triggers_then_emr_work']) retrieved from /home/ec2-user/airflow/dags/three_s3_triggers_then_emr_work.py
[2018-05-31 21:15:12,309] {models.py:341} INFO - Finding 'running' jobs without a recent heartbeat
[2018-05-31 21:15:12,309] {models.py:345} INFO - Failing jobs without heartbeat after 2018-05-31 21:10:12.309615
[2018-05-31 21:15:12,311] {models.py:341} INFO - Finding 'running' jobs without a recent heartbeat
[2018-05-31 21:15:12,311] {models.py:345} INFO - Failing jobs without heartbeat after 2018-05-31 21:10:12.311879
[2018-05-31 21:15:12,314] {jobs.py:375} INFO - Processing /home/ec2-user/airflow/dags/three_s3_triggers_then_emr_work.py took 0.267 seconds
[2018-05-31 21:15:12,316] {jobs.py:375} INFO - Processing /home/ec2-user/airflow/dags/s3_triggered_emr_cluster_dag.py took 0.265 seconds
[2018-05-31 21:15:13,057] {jobs.py:1627} INFO - Heartbeating the process manager
[2018-05-31 21:15:13,057] {dag_processing.py:468} INFO - Processor for /home/ec2-user/airflow/dags/three_s3_triggers_then_emr_work.py finished
[2018-05-31 21:15:13,057] {dag_processing.py:468} INFO - Processor for /home/ec2-user/airflow/dags/s3_triggered_emr_cluster_dag.py finished
[2018-05-31 21:15:13,060] {dag_processing.py:537} INFO - Started a process (PID: 19219) to generate tasks for /home/ec2-user/airflow/dags/s3_sensor_connection_test.py
[2018-05-31 21:15:13,062] {dag_processing.py:537} INFO - Started a process (PID: 19220) to generate tasks for /home/ec2-user/airflow/dags/myDag.py
[2018-05-31 21:15:13,063] {jobs.py:1662} INFO - Heartbeating the executor
[2018-05-31 21:15:13,064] {jobs.py:368} INFO - Started process (PID=19219) to work on /home/ec2-user/airflow/dags/s3_sensor_connection_test.py
[2018-05-31 21:15:13,068] {jobs.py:368} INFO - Started process (PID=19220) to work on /home/ec2-user/airflow/dags/myDag.py
[2018-05-31 21:15:13,130] {jobs.py:1742} INFO - Processing file /home/ec2-user/airflow/dags/s3_sensor_connection_test.py for tasks to queue
[2018-05-31 21:15:13,130] {models.py:189} INFO - Filling up the DagBag from /home/ec2-user/airflow/dags/s3_sensor_connection_test.py
[2018-05-31 21:15:13,134] {jobs.py:1742} INFO - Processing file /home/ec2-user/airflow/dags/myDag.py for tasks to queue
[2018-05-31 21:15:13,134] {models.py:189} INFO - Filling up the DagBag from /home/ec2-user/airflow/dags/myDag.py
[2018-05-31 21:15:13,189] {jobs.py:1754} INFO - DAG(s) dict_keys(['example_trigger_controller_dag', 'example_python_operator', 'example_skip_dag', 'test_utils', 'example_xcom', 'example_passing_params_via_test_command', 'latest_only', 'example_trigger_target_dag', 'example_branch_operator', 'example_http_operator', 'example_branch_dop_operator_v3', 'example_subdag_operator', 'example_subdag_operator.section-1', 'example_subdag_operator.section-2', 'latest_only_with_trigger', 'example_bash_operator', 'tutorial', 'example_short_circuit_operator', 'myDag']) retrieved from /home/ec2-user/airflow/dags/myDag.py
[2018-05-31 21:15:13,315] {models.py:341} INFO - Finding 'running' jobs without a recent heartbeat
[2018-05-31 21:15:13,316] {models.py:345} INFO - Failing jobs without heartbeat after 2018-05-31 21:10:13.316206
[2018-05-31 21:15:13,321] {jobs.py:375} INFO - Processing /home/ec2-user/airflow/dags/s3_sensor_connection_test.py took 0.257 seconds
[2018-05-31 21:15:13,333] {models.py:341} INFO - Finding 'running' jobs without a recent heartbeat
[2018-05-31 21:15:13,334] {models.py:345} INFO - Failing jobs without heartbeat after 2018-05-31 21:10:13.334021
[2018-05-31 21:15:13,338] {jobs.py:375} INFO - Processing /home/ec2-user/airflow/dags/myDag.py took 0.270 seconds
[2018-05-31 21:15:14,065] {jobs.py:1627} INFO - Heartbeating the process manager
[2018-05-31 21:15:14,066] {dag_processing.py:468} INFO - Processor for /home/ec2-user/airflow/dags/s3_sensor_connection_test.py finished
[2018-05-31 21:15:14,066] {dag_processing.py:468} INFO - Processor for /home/ec2-user/airflow/dags/myDag.py finished
[2018-05-31 21:15:14,068] {dag_processing.py:537} INFO - Started a process (PID: 19225) to generate tasks for /home/ec2-user/airflow/dags/Test_Dag_Create_EMR.py
[2018-05-31 21:15:14,069] {jobs.py:1662} INFO - Heartbeating the executor
[2018-05-31 21:15:14,072] {jobs.py:368} INFO - Started process (PID=19225) to work on /home/ec2-user/airflow/dags/Test_Dag_Create_EMR.py
[2018-05-31 21:15:14,187] {jobs.py:1742} INFO - Processing file /home/ec2-user/airflow/dags/Test_Dag_Create_EMR.py for tasks to queue
[2018-05-31 21:15:14,188] {models.py:189} INFO - Filling up the DagBag from /home/ec2-user/airflow/dags/Test_Dag_Create_EMR.py
[2018-05-31 21:15:14,239] {jobs.py:1754} INFO - DAG(s) dict_keys(['example_trigger_controller_dag', 'example_python_operator', 'example_skip_dag', 'test_utils', 'example_xcom', 'example_passing_params_via_test_command', 'latest_only', 'example_trigger_target_dag', 'example_branch_operator', 'example_http_operator', 'example_branch_dop_operator_v3', 'example_subdag_operator', 'example_subdag_operator.section-1', 'example_subdag_operator.section-2', 'latest_only_with_trigger', 'example_bash_operator', 'tutorial', 'example_short_circuit_operator', 'kyles_dag']) retrieved from /home/ec2-user/airflow/dags/Test_Dag_Create_EMR.py
[2018-05-31 21:15:14,366] {models.py:341} INFO - Finding 'running' jobs without a recent heartbeat
[2018-05-31 21:15:14,366] {models.py:345} INFO - Failing jobs without heartbeat after 2018-05-31 21:10:14.366593
[2018-05-31 21:15:14,371] {jobs.py:375} INFO - Processing /home/ec2-user/airflow/dags/Test_Dag_Create_EMR.py took 0.299 seconds
[2018-05-31 21:15:15,071] {jobs.py:1627} INFO - Heartbeating the process manager
Note: I don't think it's very relevant for this question but I'm running Airflow on an Amazon EC2-Instance.
I'm not sure which of these steps exactly solved my problem and I'm not sure exactly what the root cause of the problem was but I did this:
I literally just reset everything. First I shut down the webserver and scheduler using kill theirPIDs or ctrl + c if it's open still in the terminal. Then I deleted all the entries under /home/ec2-user/airflow/dags/__pycache__. Then I restarted the postgre database using sudo /etc/init.d/postgresql restart then I ran airflow resetdb. Then I reran airflow webserver and airflow scheduler. I went in the UI and turned on the DAG and voila it went into the running state and then worked successfully. No idea what was going on though.....
Related
Why if dag is turned off, then SparkSubmitOperator kills itself 5 minutes after startup?
I brought out the dag with SparkSubmitOperator. I turned it on so that it would create a task. And then turned it off so that it wouldn't create new ones. After that, I started running the task. And 5 minutes after the launch, he always sent himself a SIGTERM with log: [2023-01-27 12:50:04,783] {local_task_job.py:188} WARNING - State of this instance has been externally set to None. Terminating instance. [2023-01-27 12:50:04,798] {process_utils.py:100} INFO - Sending Signals.SIGTERM to GPID 968 [2023-01-27 12:50:04,802] {taskinstance.py:1265} ERROR - Received SIGTERM. Terminating subprocesses. [2023-01-27 12:50:04,804] {spark_submit.py:657} INFO - Sending kill signal to spark-submit [2023-01-27 12:50:15,985] {spark_submit.py:674} INFO - YARN app killed with return code: 0 [2023-01-27 12:50:16,122] {taskinstance.py:1482} ERROR - Task failed with exception Traceback (most recent call last): File "/home/airflow/.local/lib/python3.6/site-packages/airflow/models/taskinstance.py", line 1138, in _run_raw_task self._prepare_and_execute_task_with_callbacks(context, task) File "/home/airflow/.local/lib/python3.6/site-packages/airflow/models/taskinstance.py", line 1311, in _prepare_and_execute_task_with_callbacks result = self._execute_task(context, task_copy) File "/home/airflow/.local/lib/python3.6/site-packages/airflow/models/taskinstance.py", line 1341, in _execute_task result = task_copy.execute(context=context) File "/home/airflow/.local/lib/python3.6/site-packages/airflow/providers/apache/spark/operators/spark_submit.py", line 183, in execute self._hook.submit(self._application) File "/home/airflow/.local/lib/python3.6/site-packages/airflow/providers/apache/spark/hooks/spark_submit.py", line 440, in submit self._process_spark_submit_log(iter(self._submit_sp.stdout)) # type: ignore File "/home/airflow/.local/lib/python3.6/site-packages/airflow/providers/apache/spark/hooks/spark_submit.py", line 494, in _process_spark_submit_log for line in itr: File "/home/airflow/.local/lib/python3.6/site-packages/airflow/models/taskinstance.py", line 1267, in signal_handler raise AirflowException("Task received SIGTERM signal") airflow.exceptions.AirflowException: Task received SIGTERM signal This error was reproduced, tried more than 5 times. But then I turned on the dag, launched it, and it worked. Why is this happening?
DAGs are supposed to stay unpaused for their tasks to run correctly. :) You can limit how many DAG runs are created by setting the DAG parameter max_active_runs to 1 and limit how many instances of a specifc task can run at any time by setting the task level parameter max_active_tis_per_dag to 1. Also make sure you set the DAG parameter catchup to False, to avoid many runs to be scheduled if your start_date is a while back in the past. This DAG should only create one running t1 task every day (based on the #daily schedule). from airflow import DAG from pendulum import datetime from airflow.operators.empty import EmptyOperator with DAG( dag_id="simple_classic_dag", start_date=datetime(2022,12,10), schedule="#daily", catchup=False, max_active_runs=1, tags=["simple", "debug"] ) as dag: t1 = EmptyOperator(task_id="t1", max_active_tis_per_dag=1) You might find these guides helpful: DAG scheduling and timetables in Airflow explains scheduling basics Scaling Airflow to optimize performance goes over scaling and limit parameters
Fluent-bit inside Spark Container
I am trying to run fluent-bit inside spark container so that spark driver container which is writing the logs in a file /var/log/sparkDriver.log controlled by spark log4j properties, can be read or consumed by fluent-bit. I know that running multiple processes in one container is an AntiParttern but right now I have no choice. What configuration I need, to read this file (/var/log/sparkDriver.log) and forward the logs to our internal splunk hec server. I know fluent-bit can be used as a sidecar in the pod but I am using simple spark-submit to submit my spark job to K8S and spark-submit doesn't have any way to tell k8s that I want to run a sidecar (fluent-bit) as well. I also know that fluent-bit can installed as deamonSet in the cluster which will basically run on each node in the k8s cluster and forward logs from the container via node to Splunk. But this option is also not going to work for me. So I thought if I could bake fluent-bit or splunkforwarder or even fluentd and read the logs from a file or stdout. I know that the other 2 options will inflate my spark docker image but I don't have an option right now. Any help or suggestion will be really appreciated I actually tried the tail and splunk but somehow I am not able to figure out the right configuration for fluent-bit Here is my log file which is spark logs using log4j: I actually tried it but somehow I am not able to put the right configuration around it. Here is how my log files look: 20/03/02 19:35:47 INFO TaskSetManager: Starting task 12526.0 in stage 0.0 (TID 12526, 172.16.7.233, executor 1, partition 12526, PROCESS_LOCAL, 7885 bytes) 20/03/02 19:35:47 DEBUG KubernetesClusterSchedulerBackend$KubernetesDriverEndpoint: Launching task 12526 on executor id: 1 hostname: 172.16.7.233. 20/03/02 19:35:47 INFO TaskSetManager: Finished task 12524.0 in stage 0.0 (TID 12524) in 1 ms on 172.16.7.233 (executor 1) (12525/1000000) 20/03/02 19:35:47 TRACE MessageDecoder: Received message OneWayMessage: OneWayMessage{body=NettyManagedBuffer{buf=CompositeByteBuf(ridx: 5, widx: 1622, cap: 1622, components=2)}} 20/03/02 19:35:47 TRACE MessageDecoder: Received message OneWayMessage: OneWayMessage{body=NettyManagedBuffer{buf=PooledUnsafeDirectByteBuf(ridx: 13, widx: 1630, cap: 32768)}} 20/03/02 19:35:47 TRACE MessageDecoder: Received message OneWayMessage: OneWayMessage{body=NettyManagedBuffer{buf=PooledUnsafeDirectByteBuf(ridx: 13, widx: 2414, cap: 4096)}} Here is my fluent-bit configuration: [INPUT] Name tail Path /var/log/sparklog.log # nest the record under the 'event' key [FILTER] Name nest Match * Operation nest Wildcard * Nest_under event # add event metadata [FILTER] Name modify Match * Add index myindex Add host ${HOSTNAME} Add app_name ${APP_NAME} Add namespace ${NAMESPACE} [OUTPUT] Name Splunk Match * Host splunk.example.com Port 30000 Splunk_Token XXXX-XXXX-XXXX-XXXX Splunk_Send_Raw On TLS On TLS.Verify Off
Tail https://docs.fluentbit.io/manual/input/tail and splunk plugin https://docs.fluentbit.io/manual/output/splunk should do the trick for you. Are you facing any specific issue with configuring these two?
slurmd unable to communicate with slurmctld
I followed the steps to troubleshoot here: https://slurm.schedmd.com/troubleshoot.html. When running scontrol show slurmd, I get: Active Steps = NONE Actual CPUs = 1 Actual Boards = 1 Actual sockets = 1 Actual cores = 1 Actual threads per core = 1 Actual real memory = 984 MB Actual temp disk space = 492 MB Boot time = 2019-03-27T17:53:56 Hostname = fedora2 Last slurmctld msg time = NONE Slurmd PID = 1549 Slurmd Debug = 4 Slurmd Logfile = /var/log/slurmd.log Version = 17.11.13-2 I don't know why slurmd on fedora2 can't communicate with the controller on fedora1. slurmctld daemon is running fine on fedora1. The slurm.conf is as follows: # slurm.conf file generated by configurator easy.html. # Put this file on all nodes of your cluster. # See the slurm.conf man page for more information. # #SlurmctldHost=fedora1 # ControlMachine=fedora1 ControlAddr=192.168.1.4 MailProg=/bin/mail MpiDefault=none #MpiParams=ports=#-# ProctrackType=proctrack/cgroup ReturnToService=1 SlurmctldPidFile=/var/run/slurm/slurmctld.pid #SlurmctldPort=6817 SlurmdPidFile=/var/run/slurm/slurmd.pid #SlurmdPort=6818 SlurmdSpoolDir=/var/spool/slurmd SlurmUser=slurm SlurmdUser=root StateSaveLocation=/var/spool/slurmctld SwitchType=switch/none TaskPlugin=task/affinity # # # TIMERS #KillWait=30 #MinJobAge=300 #SlurmctldTimeout=120 #SlurmdTimeout=300 # # # SCHEDULING FastSchedule=1 SchedulerType=sched/backfill SelectType=select/cons_res SelectTypeParameters=CR_Core # # # LOGGING AND ACCOUNTING AccountingStorageType=accounting_storage/none ClusterName=fedora #JobAcctGatherFrequency=30 JobAcctGatherType=jobacct_gather/none SlurmctldDebug=verbose SlurmctldLogFile=/var/log/slurmctld.log SlurmdDebug=verbose SlurmdLogFile=/var/log/slurmd.log # # # COMPUTE NODES NodeName=fedora1 NodeAddr=192.168.1.4 CPUs=1 State=UNKNOWN NodeName=fedora2 NodeAddr=192.168.1.5 CPUs=1 State=UNKNOWN PartitionName=debug Nodes=fedora[1-2] Default=YES MaxTime=INFINITE State=UP The output of tail /var/log/slurmd.log on fedora2, on multiple lines: error: Unable to register: Unable to contact slurm controller (connect failure)
Make sure that: no firewall prevents the slurmd daemon from talking to the controller munge is running on each server the dates are in sync the Slurm versions are identical the name fedora1 can be resolved to the correct IP
Airflow Logs BrokenPipeException
I'm using a clustered Airflow environment where I have four AWS ec2-instances for the servers. ec2-instances Server 1: Webserver, Scheduler, Redis Queue, PostgreSQL Database Server 2: Webserver Server 3: Worker Server 4: Worker My setup has been working perfectly fine for three months now but sporadically about once a week I get a Broken Pipe Exception when Airflow is attempting to log something. *** Log file isn't local. *** Fetching here: http://ip-1-2-3-4:8793/log/foobar/task_1/2018-07-13T00:00:00/1.log [2018-07-16 00:00:15,521] {cli.py:374} INFO - Running on host ip-1-2-3-4 [2018-07-16 00:00:15,698] {models.py:1197} INFO - Dependencies all met for <TaskInstance: foobar.task_1 2018-07-13 00:00:00 [queued]> [2018-07-16 00:00:15,710] {models.py:1197} INFO - Dependencies all met for <TaskInstance: foobar.task_1 2018-07-13 00:00:00 [queued]> [2018-07-16 00:00:15,710] {models.py:1407} INFO - -------------------------------------------------------------------------------- Starting attempt 1 of 1 -------------------------------------------------------------------------------- [2018-07-16 00:00:15,719] {models.py:1428} INFO - Executing <Task(OmegaFileSensor): task_1> on 2018-07-13 00:00:00 [2018-07-16 00:00:15,720] {base_task_runner.py:115} INFO - Running: ['bash', '-c', 'airflow run foobar task_1 2018-07-13T00:00:00 --job_id 1320 --raw -sd DAGS_FOLDER/datalake_digitalplatform_arl_workflow_schedule_test_2.py'] [2018-07-16 00:00:16,532] {base_task_runner.py:98} INFO - Subtask: [2018-07-16 00:00:16,532] {configuration.py:206} WARNING - section/key [celery/celery_ssl_active] not found in config [2018-07-16 00:00:16,532] {base_task_runner.py:98} INFO - Subtask: [2018-07-16 00:00:16,532] {default_celery.py:41} WARNING - Celery Executor will run without SSL [2018-07-16 00:00:16,534] {base_task_runner.py:98} INFO - Subtask: [2018-07-16 00:00:16,533] {__init__.py:45} INFO - Using executor CeleryExecutor [2018-07-16 00:00:16,597] {base_task_runner.py:98} INFO - Subtask: [2018-07-16 00:00:16,597] {models.py:189} INFO - Filling up the DagBag from /home/ec2-user/airflow/dags/datalake_digitalplatform_arl_workflow_schedule_test_2.py [2018-07-16 00:00:16,768] {cli.py:374} INFO - Running on host ip-1-2-3-4 [2018-07-16 00:16:24,931] {logging_mixin.py:84} WARNING - --- Logging error --- [2018-07-16 00:16:24,931] {logging_mixin.py:84} WARNING - Traceback (most recent call last): [2018-07-16 00:16:24,931] {logging_mixin.py:84} WARNING - File "/usr/lib64/python3.6/logging/__init__.py", line 996, in emit self.flush() [2018-07-16 00:16:24,932] {logging_mixin.py:84} WARNING - File "/usr/lib64/python3.6/logging/__init__.py", line 976, in flush self.stream.flush() [2018-07-16 00:16:24,932] {logging_mixin.py:84} WARNING - BrokenPipeError: [Errno 32] Broken pipe [2018-07-16 00:16:24,932] {logging_mixin.py:84} WARNING - Call stack: [2018-07-16 00:16:24,933] {logging_mixin.py:84} WARNING - File "/usr/bin/airflow", line 27, in <module> args.func(args) [2018-07-16 00:16:24,934] {logging_mixin.py:84} WARNING - File "/usr/local/lib/python3.6/site-packages/airflow/bin/cli.py", line 392, in run pool=args.pool, [2018-07-16 00:16:24,934] {logging_mixin.py:84} WARNING - File "/usr/local/lib/python3.6/site-packages/airflow/utils/db.py", line 50, in wrapper result = func(*args, **kwargs) [2018-07-16 00:16:24,934] {logging_mixin.py:84} WARNING - File "/usr/local/lib/python3.6/site-packages/airflow/models.py", line 1488, in _run_raw_task result = task_copy.execute(context=context) [2018-07-16 00:16:24,934] {logging_mixin.py:84} WARNING - File "/usr/local/lib/python3.6/site-packages/airflow/operators/sensors.py", line 78, in execute while not self.poke(context): [2018-07-16 00:16:24,934] {logging_mixin.py:84} WARNING - File "/home/ec2-user/airflow/plugins/custom_plugins.py", line 35, in poke directory = os.listdir(full_path) [2018-07-16 00:16:24,934] {logging_mixin.py:84} WARNING - File "/usr/local/lib/python3.6/site-packages/airflow/utils/timeout.py", line 36, in handle_timeout self.log.error("Process timed out") [2018-07-16 00:16:24,934] {logging_mixin.py:84} WARNING - Message: 'Process timed out' Arguments: () [2018-07-16 00:16:24,942] {models.py:1595} ERROR - Timeout Traceback (most recent call last): File "/usr/local/lib/python3.6/site-packages/airflow/models.py", line 1488, in _run_raw_task result = task_copy.execute(context=context) File "/usr/local/lib/python3.6/site-packages/airflow/operators/sensors.py", line 78, in execute while not self.poke(context): File "/home/ec2-user/airflow/plugins/custom_plugins.py", line 35, in poke directory = os.listdir(full_path) File "/usr/local/lib/python3.6/site-packages/airflow/utils/timeout.py", line 37, in handle_timeout raise AirflowTaskTimeout(self.error_message) airflow.exceptions.AirflowTaskTimeout: Timeout [2018-07-16 00:16:24,942] {models.py:1624} INFO - Marking task as FAILED. [2018-07-16 00:16:24,956] {models.py:1644} ERROR - Timeout Sometimes the error will also say *** Log file isn't local. *** Fetching here: http://ip-1-2-3-4:8793/log/foobar/task_1/2018-07-12T00:00:00/1.log *** Failed to fetch log file from worker. 404 Client Error: NOT FOUND for url: http://ip-1-2-3-4:8793/log/foobar/task_1/2018-07-12T00:00:00/1.log I'm not sure why the logs are working ~95% of the time but are randomly failing at other times. Here are my log settings in my Airflow.cfg file, # The folder where airflow should store its log files # This path must be absolute base_log_folder = /home/ec2-user/airflow/logs # Airflow can store logs remotely in AWS S3 or Google Cloud Storage. Users # must supply an Airflow connection id that provides access to the storage # location. remote_log_conn_id = encrypt_s3_logs = False # Logging level logging_level = INFO # Logging class # Specify the class that will specify the logging configuration # This class has to be on the python classpath # logging_config_class = my.path.default_local_settings.LOGGING_CONFIG logging_config_class = # Log format log_format = [%%(asctime)s] {%%(filename)s:%%(lineno)d} %%(levelname)s - %%(message)s simple_log_format = %%(asctime)s %%(levelname)s - %%(message)s # Name of handler to read task instance logs. # Default to use file task handler. task_log_reader = file.task # Log files for the gunicorn webserver. '-' means log to stderr. access_logfile = - error_logfile = # The amount of time (in secs) webserver will wait for initial handshake # while fetching logs from other worker machine log_fetch_timeout_sec = 5 # When you start an airflow worker, airflow starts a tiny web server # subprocess to serve the workers local log files to the airflow main # web server, who then builds pages and sends them to users. This defines # the port on which the logs are served. It needs to be unused, and open # visible from the main web server to connect into the workers. worker_log_server_port = 8793 # How often should stats be printed to the logs print_stats_interval = 30 child_process_log_directory = /home/ec2-user/airflow/logs/scheduler I'm wondering if maybe I should try a different technique for my logging such as writing to an S3 Bucket or if there is something else I can do to fix this issue. Update: Writing the logs to S3 did not resolve this issue. Also, the error is more consistent now (still sporadic). It's happening more like 50% of the time now. One thing I noticed is that the task it's happening on is my AWS EMR creation task. Starting an AWS EMR cluster takes about 20 minutes and then the task has to wait for the Spark commands to run on the EMR cluster. So the single task is running for about 30 minutes. I'm wondering if this is too long for an Airflow task to be running and if that's why it starts to fail writing to the logs. If this is the case then I could breakup the EMR task so that there is one task for the EMR creation, then another task for the Spark commands on the EMR cluster. Note: I've also created a new bug ticket on Airflow's Jira here https://issues.apache.org/jira/browse/AIRFLOW-2844
This issue is a symptom of another issue I just resolved here AirflowException: Celery command failed - The recorded hostname does not match this instance's hostname. I didn't see the AirflowException: Celery command failed for a while because it showed up on the airflow worker logs. It wasn't until I watched the airflow worker logs in real time that I saw when the error is thrown I also got the BrokenPipeException in my task. It gets somewhat weirder though. I would only see the BrokenPipeException thrown if I did print("something to log") and the AirflowException: Celery command failed... error happened on the Worker node. When I changed all of my print statements to use import logging ... logging.info("something to log") then I would not see the BrokenPipeException but the task would still fail because of the AirflowException: Celery command failed... error. But had I not seen the BrokenPipeException being thrown in my Airflow task logs I wouldn't have known why the task was failing because once I eliminated the print statements I never saw any error in the Airflow task logs (only on the $airflow worker logs) So long story short there are a few take aways. Don't do print("something to log") use Airflow's built in logging by importing logging and then using the logging class like import logging then logging.info("something to log") If you're using an AWS EC2-Instance as your server for Airflow then you may be experiencing this issue: https://github.com/apache/incubator-airflow/pull/2484 a fix to this issue has already been integrated into Airflow Version 1.10 (I'm currently using Airflow Version 1.9). So upgrade your Airflow version to 1.10. You can also use the command here pip install git+git://github.com/apache/incubator-airflow.git#v1-10-stable. Also, if you don't want to upgrade your Airflow version then you could follow the steps on the github issue to either manually update the file with the fix or fork Airflow and cherry pick the commit that fixes it.
How to enable a Spark-Mesos job to be launched from inside a Docker container?
Summary: Is it possible to submit a Spark job on Mesos from inside a Docker container with 1 Mesos master (no Zookeeper) and 1 Mesos agent also each running in separate Docker containers (on the same host for now)? The Mesos containerizer described at http://mesos.apache.org/documentation/latest/container-image/ seems to apply to the case where the Mesos application is simply encapsulated in a Docker container and run. My Docker application is more interactive with multiple PySpark Mesos jobs being instantiated at run-time based on user input. The driver program in the Docker container is not itself run as a Mesos app. Only the user-initiated job requests are handled as PySpark Mesos apps. Specifics: I have 3 Docker containers based on centos:7 linux, and running on the same host machine for now: Container "Master" running a Mesos Master. Container "Agent" running a Mesos Agent. Container "Test" with Spark and Mesos installed where I run a bash shell and launch the following PySpark test program from the command line. from pyspark import SparkContext, SparkConf from operator import add # Configure Spark sp_conf = SparkConf() sp_conf.setAppName("spark_test") sp_conf.set("spark.scheduler.mode", "FAIR") sp_conf.set("spark.dynamicAllocation.enabled", "false") sp_conf.set("spark.driver.memory", "500m") sp_conf.set("spark.executor.memory", "500m") sp_conf.set("spark.executor.cores", 1) sp_conf.set("spark.cores.max", 1) sp_conf.set("spark.mesos.executor.home", "/usr/local/spark-2.1.0") sp_conf.set("spark.executor.uri", "file://usr/local/spark-2.1.0-bin-without-hadoop.tgz") sc = SparkContext(conf=sp_conf) # Simple computation x = [(1.5,100.),(1.5,200.),(1.5,300.),(2.5,150.)] rdd = sc.parallelize(x,1) tot = rdd.foldByKey(0,add).collect() cnt = rdd.countByKey() time = [t[0] for t in tot] avg = [t[1]/cnt[t[0]] for t in tot] print 'tot=', tot print 'cnt=', cnt print 't=', time print 'avg=', avg The relevant software versions I am using are as follows: Hadoop: 2.7.3 Spark: 2.1.0 Mesos: 1.2.0 Docker: 17.03.1-ce, build c6d412e The following works fine: I can run the simple PySpark test program above from inside the Test container with Spark's MASTER=local[N] for N=1 or N=4. I can see in the Mesos logs and in the Mesos user interface (UI) that the Mesos agent and master come up fine. The Mesos UI shows that the agent is connected with plenty of resources (cpu, memory, disk). I can run the Mesos Python tests successfully from inside the Test container with /usr/local/mesos-1.2.0/build/src/examples/python/test-framework 127.0.0.1:5050. This seems to confirm that the Mesos containers can be accessed from within my Test container, but these tests are not using Spark. This is the Failure: With Spark's MASTER=mesos://127.0.0.1:5050, when I launch my PySpark test program from inside the Test container there is activity in the logs of both the Mesos Master and Agent, and in the couple seconds before failure, the Mesos UI shows resources assigned for the job that are well within what is available. However, the PySpark test program then fails with: WARN scheduler.TaskSchedulerImpl: Initial job has not accepted any resources; check your cluster UI to ensure that workers are registered and have sufficient resources. The steps I followed are as follows. Start Mesos Master: docker run -it --net=host -p 5050:5050 the_master Relevant excerpts from the master's log shows: I0418 01:05:08.540192 27 master.cpp:383] Master 15b354eb-6a20-4bc9-a13b-6533b1e91bd2 (localhost) started on 127.0.0.1:5050 I0418 01:05:08.540210 27 master.cpp:385] Flags at startup: --agent_ping_timeout="15secs" --agent_reregister_timeout="10mins" --allocation_interval="1secs" --allocator="HierarchicalDRF" --authenticate_agents="false" --authenticate_frameworks="false" --authenticate_http_frameworks="false" --authenticate_http_readonly="false" --authenticate_http_readwrite="false" --authenticators="crammd5" --authorizers="local" --framework_sorter="drf" --help="false" --hostname_lookup="true" --http_authenticators="basic" --initialize_driver_logging="true" --log_auto_initialize="true" --logbufsecs="0" --logging_level="INFO" --max_agent_ping_timeouts="5" --max_completed_frameworks="50" --max_completed_tasks_per_framework="1000" --max_unreachable_tasks_per_framework="1000" --quiet="false" --recovery_agent_removal_limit="100%" --registry="replicated_log" --registry_fetch_timeout="1mins" --registry_gc_interval="15mins" --registry_max_agent_age="2weeks" --registry_max_agent_count="102400" --registry_store_timeout="20secs" --registry_strict="false" --root_submissions="true" --user_sorter="drf" --version="false" --webui_dir="/usr/local/mesos-1.2.0/build/../src/webui" --work_dir="/var/lib/mesos" --zk_session_timeout="10secs" Start Mesos Agent: docker run -it --net=host -e MESOS_AGENT_PORT=5051 the_agent The agent's log shows: I0418 01:42:00.234244 40 slave.cpp:212] Flags at startup: --appc_simple_discovery_uri_prefix="http://" --appc_store_dir="/tmp/mesos/store/appc" --authenticate_http_readonly="false" --authenticate_http_readwrite="false" --authenticatee="crammd5" --authentication_backoff_factor="1secs" --authorizer="local" --cgroups_cpu_enable_pids_and_tids_count="false" --cgroups_enable_cfs="false" --cgroups_hierarchy="/sys/fs/cgroup" --cgroups_limit_swap="false" --cgroups_root="mesos" --container_disk_watch_interval="15secs" --containerizers="mesos" --default_role="*" --disk_watch_interval="1mins" --docker="docker" --docker_kill_orphans="true" --docker_mesos_image="spark-mesos-agent-test" --docker_registry="https://registry-1.docker.io" --docker_remove_delay="6hrs" --docker_socket="/var/run/docker.sock" --docker_stop_timeout="0ns" --docker_store_dir="/tmp/mesos/store/docker" --docker_volume_checkpoint_dir="/var/run/mesos/isolators/docker/volume" --enforce_container_disk_quota="false" --executor_registration_timeout="1mins" --executor_shutdown_grace_period="5secs" --fetcher_cache_dir="/tmp/mesos/fetch" --fetcher_cache_size="2GB" --frameworks_home="" --gc_delay="1weeks" --gc_disk_headroom="0.1" --hadoop_home="" --help="false" --hostname_lookup="true" --http_authenticators="basic" --http_command_executor="false" --http_heartbeat_interval="30secs" --initialize_driver_logging="true" --isolation="posix/cpu,posix/mem" --launcher="posix" --launcher_dir="/usr/local/mesos-1.2.0/build/src" --logbufsecs="0" --logging_level="INFO" --max_completed_executors_per_framework="150" --oversubscribed_resources_interval="15secs" --perf_duration="10secs" --perf_interval="1mins" --qos_correction_interval_min="0ns" --quiet="false" --recover="reconnect" --recovery_timeout="15mins" --registration_backoff_factor="1secs" --revocable_cpu_low_priority="true" --runtime_dir="/var/run/mesos" --sandbox_directory="/mnt/mesos/sandbox" --strict="true" --switch_user="false" --systemd_enable_support="false" --systemd_runtime_directory="/run/systemd/system" --version="false" --work_dir="/var/lib/mesos" I get the following warning for both the Mesos Master and Agent, but ignore it because I am running everything on the same host for now: Master/Agent bound to loopback interface! Cannot communicate with remote schedulers or agents. You might want to set '--ip' flag to a routable IP address. In fact, my tests with assigning a routable IP address instead of 127.0.0.1 failed to change any of the behavior I describe here. Start Test Container (with bash shell for testing): docker run -it --net=host the_test /bin/bash Some relevant environment variables set inside all three container (Master, Agent, and Test): HADOOP_HOME=/usr/local/hadoop-2.7.3 HADOOP_CONF_DIR=/usr/local/hadoop-2.7.3/etc/hadoop SPARK_HOME=/usr/local/spark-2.1.0 SPARK_EXECUTOR_URI=file:////usr/local/spark-2.1.0-bin-without-hadoop.tgz MASTER=mesos://127.0.0.1:5050 PYSPARK_PYTHON=/usr/local/anaconda2/bin/python PYSPARK_DRIVER_PYTHON=/usr/local/anaconda2/bin/python PYSPARK_SUBMIT_ARGS=--driver-memory=4g pyspark-shell MESOS_PORT=5050 MESOS_IP=127.0.0.1 MESOS_WORKDIR=/var/lib/mesos MESOS_HOME=/usr/local/mesos-1.2.0 MESOS_NATIVE_JAVA_LIBRARY=/usr/local/lib/libmesos.so MESOS_MASTER=mesos://127.0.0.1:5050 PYTHONPATH=:/usr/local/spark-2.1.0/python:/usr/local/spark-2.1.0/python/lib/py4j-0.10.1-src.zip Run Mesos (non-Spark) tests from inside the Test container: /usr/local/mesos-1.2.0/build/src/examples/python/test-framework 127.0.0.1:5050 This produces the following log output (as expected I think): I0417 21:28:36.912542 20 sched.cpp:232] Version: 1.2.0 I0417 21:28:36.920013 62 sched.cpp:336] New master detected at master#127.0.0.1:5050 I0417 21:28:36.920472 62 sched.cpp:352] No credentials provided. Attempting to register without authentication I0417 21:28:36.924165 62 sched.cpp:759] Framework registered with be89e739-be8d-430e-b1e9-3fe55fa18459-0000 Registered with framework ID be89e739-be8d-430e-b1e9-3fe55fa18459-0000 Received offer be89e739-be8d-430e-b1e9-3fe55fa18459-O0 with cpus: 16.0 and mem: 119640.0 Launching task 0 using offer be89e739-be8d-430e-b1e9-3fe55fa18459-O0 Launching task 1 using offer be89e739-be8d-430e-b1e9-3fe55fa18459-O0 Launching task 2 using offer be89e739-be8d-430e-b1e9-3fe55fa18459-O0 Launching task 3 using offer be89e739-be8d-430e-b1e9-3fe55fa18459-O0 Launching task 4 using offer be89e739-be8d-430e-b1e9-3fe55fa18459-O0 Task 0 is in state TASK_RUNNING Task 1 is in state TASK_RUNNING Task 2 is in state TASK_RUNNING Task 3 is in state TASK_RUNNING Task 4 is in state TASK_RUNNING Task 0 is in state TASK_FINISHED Task 1 is in state TASK_FINISHED Task 2 is in state TASK_FINISHED Task 3 is in state TASK_FINISHED Task 4 is in state TASK_FINISHED All tasks done, waiting for final framework message Received message: 'data with a \x00 byte' Received message: 'data with a \x00 byte' Received message: 'data with a \x00 byte' Received message: 'data with a \x00 byte' Received message: 'data with a \x00 byte' All tasks done, and all messages received, exiting Run PySpark test program from inside the Test container: python spark_test.py This produces the following log output: 17/04/17 21:29:18 WARN util.NativeCodeLoader: Unable to load native-hadoop library for your platform... using builtin-java classes where applicable I0417 21:29:19.187747 205 sched.cpp:232] Version: 1.2.0 I0417 21:29:19.196535 188 sched.cpp:336] New master detected at master#127.0.0.1:5050 I0417 21:29:19.197453 188 sched.cpp:352] No credentials provided. Attempting to register without authentication I0417 21:29:19.201884 195 sched.cpp:759] Framework registered with be89e739-be8d-430e-b1e9-3fe55fa18459-0001 17/04/17 21:29:34 WARN scheduler.TaskSchedulerImpl: Initial job has not accepted any resources; check your cluster UI to ensure that workers are registered and have sufficient resources I searched for this error on the internet but every page I found indicates that it is a common error caused by insufficient resources being allocated to the Mesos agent. As I mentioned, the Mesos UI indicates that there are sufficient resources. Please respond if you have any idea why my Spark job is not accepting resources from Mesos or if you have any suggestions of things I could try. Thank you for your help.
This error is now resolved. In case anybody encounters a similar problem, I wanted to post that in my case it was caused by the HADOOP CLASSPATH not being set in the Mesos Master and Agent containers. Once set, everything works as expected.