Can't start airflow 3 on Ubuntu 22.04 in WSL 2

[klonuo]

Apache Airflow version

3.0.0

If "Other Airflow 2 version" selected, which one?

No response

What happened?

I'm on Windows 11 with WSL 2, and using virtualenv with pip to install airflow:

pip install -U "apache-airflow[celery]==3.0.0" --constraint "https://raw.githubusercontent.com/apache/airflow/constraints-3.0.0/constraints-3.12.txt"

I can run airflow 2.10.5 without issues, while when I try current 3.0 I can't start the server ("child process died"):

I suspect problem with the new fastapi backend.

I tried using gevent: _AIRFLOW_PATCH_GEVENT=True, but it's the same result.

Any ideas how to approach to solve this?

What you think should happen instead?

No response

How to reproduce

run $ airflow api-server

Operating System

Ubuntu 22.04.5 LTS

Versions of Apache Airflow Providers

No response

Deployment

Virtualenv installation

Deployment details

No response

Anything else?

No response

Are you willing to submit PR?

• Yes I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct

[boring-cyborg[bot]]

Thanks for opening your first issue here! Be sure to follow the issue template! If you are willing to raise PR to address this issue please do so, no need to wait for approval.

[potiuk]

Converted to a discussion - WSL2 is not a "target" platform for us, but if someone who uses it and would like to investigate and share their experiences, this discussion might be helpful

[potiuk]

I think the way you can approach it @klonuo is to look at more logs - system logs, airflow logs - any other logs you can find. Somewhere somethign is likely writing what and why happened - but without seeing the reason, it's next to impossible to guess what's going on.

It might be as simple as not having enough resources (memory, CPU, disk, etc. allocated for your VM or as complex as some missing permissions. But without you deeging deeper, it's quite impossible to guess what is wrong in your case

[retsilla]

I have also faced this issue trying to get Airflow 3.0 running on a Raspberry Pi 4 with two API server workers (this setup did previously work fine on Airflow 2).

The issue seems to be related to newer versions of uvicorn (>=0.30.0) running on slower machines not allowing enough time for the child processes to start. Relevant discussions: Kludex/uvicorn#2450 and Kludex/uvicorn#2506.

Two solutions that worked for me:

1. Set AIRFLOW__API__WORKERS=1, this prevents uvicorn launching child processes avoiding the timeout issue.
2. Downgrade to uvicorn==0.29.0 which uses the older and quicker method for launching child processes meaning you can use more than 1 worker.

[atomsovic]

I have also faced this issue when running airflow on a linux VM (dockerized) - 3.0.2 works fine in my dockerized WSL2, but the smaller (but still well in excess of the reqs) resources of my VM i think are causing the uvicorn crashing. Solution 1 worked for me and i didn't try solution 2

[schunlee]

Set AIRFLOW__API__WORKERS=1, this prevents uvicorn launching child processes avoiding the timeout issue.

thanks, it works for me.
after modification, 8080 be on listening, and UI can be visited.

[EvertonSA]

I know it does not help much but it works for me on python 3.13 wsl2 22.04 on windows 11 just fine.
I'm not even sure if the way i run is supported but it works for me.

I use uv and this is my pyproject:

[project]
name = "airflow-local"
version = "0.1.0"
description = "Add your description here"
readme = "README.md"
requires-python = ">=3.13"
dependencies = [
    "apache-airflow-providers-databricks>=6.5.0",
    "apache-airflow-providers-fab>=2.0.2",
    "apache-airflow[celery]>=3.0.1",
    "asyncpg>=0.30.0",
    "azure-monitor-ingestion>=1.0.4",
    "pandas>=2.2.3",
    "psycopg2-binary>=2.9.10",
    "pyarrow>=20.0.0",
]

## Running components (on different terminal tabs)

uv run airflow api-server --port 8080

uv run airflow scheduler

uv run airflow dag-processor

uv run airflow triggerer

uv run airflow celery worker

[anzhi0708]

Same issue on WSL2 Debian

[potiuk]

Did you check why your processes were killed? Wht your deployment logs tell you @anzhi0708 ?

[anzhi0708]

I just tried limiting the number of API workers to 1 and moved the file path to the native WSL directory, and that resolved the issue. Previously, starting in standalone mode would result in a "child process died" error.