Andrushika commented on issue #70117:
URL: https://github.com/apache/airflow/issues/70117#issuecomment-5032559583
I tried to reproduce this and I think I can confirm the hang mechanism. I
could not run the full Celery setup, but I tested what happens when the child's
exit status is taken by someone else. Tested on main (16278347df) with psutil
7.2.2, on both macOS and Linux:
```python
import os, time, psutil
pid = os.fork()
if pid == 0:
os._exit(42)
proc = psutil.Process(pid)
time.sleep(0.2)
os.waitpid(pid, 0) # exit status consumed by someone else
print(proc.wait(timeout=0)) # -> None, no exception
```
So `wait(timeout=0)` returns `None` here, it does not raise. But
`_check_subprocess_exit`
([supervisor.py:1139](https://github.com/apache/airflow/blob/main/task-sdk/src/airflow/sdk/execution_time/supervisor.py#L1139))
only handles an int return or `TimeoutExpired`. So `_exit_code` stays `None`
forever, and the monitor loop
([supervisor.py:1551](https://github.com/apache/airflow/blob/main/task-sdk/src/airflow/sdk/execution_time/supervisor.py#L1551))
never exits. I think this matches what you saw: ECHILD, no zombie children,
and the socket cleanup never fires.
> dumb-init (PID 1) reaps the child via its waitpid(-1) loop
I am not sure if this error path is correct, since `init` should only be
able to reap the orphan process.
--
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]
