potiuk commented on issue #34612:
URL: https://github.com/apache/airflow/issues/34612#issuecomment-1758907339
While I understand why the liveness probe mentioned by @Aakcht (because it
runs the app directly) in Helm chart could fail in this case, I do not think
the "worker" should have this problem.
I have no idea how this would not work for `worker`. I tried to reproduce it
localy and could not:
```
root@7d9718db3570:/opt/airflow# cat /tmp/x
#!/bin/bash
echo -n "x"
root@7d9718db3570:/opt/airflow# AIRFLOW__CELERY__BROKER_URL_CMD=/tmp/x
airflow celery worker
-------------- celery@7d9718db3570 v5.3.4 (emerald-rush)
--- ***** -----
-- ******* ---- Linux-5.15.49-linuxkit-pr-aarch64-with-glibc2.17 2023-10-12
04:32:34
- *** --- * ---
- ** ---------- [config]
- ** ---------- .> app:
airflow.providers.celery.executors.celery_executor:0xffff9a8438b0
- ** ---------- .> transport: amqp://guest:**@x:5672//
- ** ---------- .> results: postgresql://postgres:**@postgres/airflow
- *** --- * --- .> concurrency: 8 (prefork)
```
The `airflow worker` command has properly:
```python
@providers_configuration_loaded
def worker(args):
```
Is there any special scenario where Celery App is run as separately started
Python interpreter when worker is started?
Do you have any other specific configuration ? @hussein-awala - can you
show how you reproduced it ?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
