Fix signal handling in triggerer job runner

[jedcunningham]

We were not registering our signal handler in the triggerer job. This meant our logging, to improve visibility into the shutdown process, was missing.

Before:

2026-01-06T22:23:41.797530Z [info     ] Starting the triggerer         [airflow.jobs.triggerer_job_runner.TriggererJobRunner] loc=triggerer_job_runner.py:166
^C2026-01-06T22:23:42.811630Z [info     ] Waiting for triggers to clean up [airflow.jobs.triggerer_job_runner.TriggererJobRunner] loc=triggerer_job_runner.py:183
2026-01-06T22:23:42.817552Z [info     ] Process exited                 [supervisor] exit_code=-2 loc=supervisor.py:716 pid=5187 signal_sent=SIGINT
2026-01-06T22:23:42.818042Z [info     ] Exited trigger loop            [airflow.jobs.triggerer_job_runner.TriggererJobRunner] loc=triggerer_job_runner.py:188

After:

2026-01-06T22:24:12.663026Z [info     ] Starting the triggerer         [airflow.jobs.triggerer_job_runner.TriggererJobRunner] loc=triggerer_job_runner.py:166
^C2026-01-06T22:24:20.586689Z [info     ] Exiting gracefully upon receiving signal 2 [airflow.jobs.triggerer_job_runner.TriggererJobRunner] loc=triggerer_job_runner.py:157
2026-01-06T22:24:20.718223Z [info     ] Waiting for triggers to clean up [airflow.jobs.triggerer_job_runner.TriggererJobRunner] loc=triggerer_job_runner.py:184
2026-01-06T22:24:20.718660Z [info     ] Process exited                 [supervisor] exit_code=0 loc=supervisor.py:716 pid=6382 signal_sent=SIGINT
2026-01-06T22:24:20.718819Z [info     ] Exited trigger loop            [airflow.jobs.triggerer_job_runner.TriggererJobRunner] loc=triggerer_job_runner.py:189

[ashb]

Since this is running async loop we souls use that for signal handling, not the sync version

https://docs.python.org/3/library/asyncio-eventloop.html#unix-signals

[uranusjr]

Makes sense, although I wonder if there’s a better way to manage these instead of have register calls in (seemingly) random places.

[uranusjr]

Using add_signal_handler is not technically required here. Signal handling is fundamentally synchronous; the loop method is needed when you want to use the eventloop (to do async stuff, for example) in the handler. We don’t here. It’s probably still a good idea to use the method anyway though as a best practice measure and to prevent future mistakes.

[github-actions]

Backport successfully created: v3-1-test

Status	Branch	Result
✅	v3-1-test