Fix pid check

[krcrouse]

related: #17507
related: #20992

This fixes issues in which running a task with impersonation leads to the error Recorded pid {PID1} does not match the current pid {PID2}, which then triggers a SIGTERM call to all processes in the group. The issue appears to be that in some cases the recorded pid (which is also the taskinstance pid) is None, which leads the ensuing psutils.Process(ti.pid).ppid() call to return the parent of the current running process instead of the parent of the taskinstance - and the parent is the long running Worker, which is not the desired process to identify.

I was able to reproduce this error regularly and separately traced all processes to try to identify what they were. The "current pid" is the task runner, and in most cases the relevant call was so short lived I couldn't even get it in my tracing - which would explain why it was no longer registered to the task instance.

[boring-cyborg]

Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contribution Guide (https://github.com/apache/airflow/blob/main/CONTRIBUTING.rst)
Here are some useful points:

• Pay attention to the quality of your code (flake8, mypy and type annotations). Our pre-commits will help you with that.
• In case of a new feature add useful documentation (in docstrings or in docs/ directory). Adding a new operator? Check this short guide Consider adding an example DAG that shows how users should use it.
• Consider using Breeze environment for testing locally, it’s a heavy docker but it ships with a working Airflow and a lot of integrations.
• Be patient and persistent. It might take some time to get a review or get the final approval from Committers.
• Please follow ASF Code of Conduct for all communication including (but not limited to) comments on Pull Requests, Mailing list and Slack.
• Be sure to read the Airflow Coding style.
  Apache Airflow is a community-driven project and together we are making it better 🚀.
  In case of doubts contact the developers at:
  Mailing List: dev@airflow.apache.org
  Slack: https://s.apache.org/airflow-slack

[uranusjr]

Is it possible to have a test for this?

[kagesenshi]

I tried applying this on my 2.2.5 install,

no improvement on my side. Adding a little print logging of ti.pid, current_pid and psutil.Process(ti.pid).ppid() shows that t.pid is same as current pid, but not the same as parent pid (eg: t.pid is 39, current_pid is 39 and ppid() is 35).

I noticed that when dag code does not have run_as_user, but airflow.cfg have default_impersonation set, ti.run_as_user or self.task_runner.run_as_user seems to evaluates to True, which caused airflow to compare current_pid with ppid() instead of with t.pid

[krcrouse]

Is it possible to have a test for this?

I just added a set of tests for this to look at when the ti.pid is None based on the different contexts of when run_as_user is not set, and in the 2 cases in which it is set. Note that only the first test currently passes on main, showing the need for this PR.

[krcrouse]

@kagesenshi, that sounds like a different issue and I haven't seen that one. This specifically addresses when the Task Instance PID is unset.

[uranusjr]

Makes sense to me

[potiuk]

Seems plausible and very interesting race condition.

@ashb WDYT?

[boring-cyborg]

Awesome work, congrats on your first merged pull request!