Properly close windows processes, discussion about implementation

ROS ROS General
1

So I went into a bit of a rabbit whole last week! CI on windows kept on getting this particular error:

2: [WARNING] [python.exe-2]: 'SIGINT' sent to process[python.exe-2] not supported on Windows, escalating to 'SIGTERM'

Apparently, windows does not have a proper way to handle SIGINT, which means that it always straight goes to the ungraceful shutdown of SIGTERM.

So I thought “oh! is that perhaps the reason why we keep getting all of the unhandy access violation ( 3221225477) that we see ever since we went switched ci to server-2025?”

The answer is… it’s not that simple…

I tried these two repositories on CI where I tried to have the testing use the proper CTRL_C_EVENT, CTRL_BREAK_EVENT signals and such:

… which resulted in this CI run with even more failures than before: https://ci.ros2.org/job/ci_windows/28952/

So this went a little too deep then I was comfortable with, but I at least tried to implement some of the suggestions given in these issues and old and closed PR

Anyway! I failed in this but perhaps someone interested to give more ideas and thoughts, and perhaps want to have a go? It would be nice to actually terminate windows nodes properly this time, and might also fix some other things in the process as well. In general there have been many complaints of ghost processes still hanging after termination, not only on Windows.

This is a list of intersting issues and PRs I saw open during my research, as it might be handy for others as well:

Love to hear your thoughts!

2 Likes
ROS PMC Minutes for August 11, 2026
ROS News for the week of August 10th, 2026
2

This is exactly what I have been chasing down in 🧑‍🌾 `test_launch_ros` generating build regressions in nightly_win by a windows access violation · Issue #539 · ros2/launch_ros · GitHub

Because launch_ros sends SIGTERM on Windows, it quite rudely shuts things down and leaves the system in a potentially bad state (which we run into with CI).

I know that @wjwwood and I have both beat our heads against this in the past (in addition to many many other folks in the community).

In theory CTRL_C_EVENT should work the way we want, but in practice I have found that it is a recipe for questioning everything you understand about how computers and reading documentation works. I would also be very grateful if someone smarter (or more foolhardy) figures out the Windows situation here. I also suspect that many of our CI flakes could be traced back to this. I suppose the alternative would be to run the same suite of tests using SIGTERM on Linux to find all of the places that we aren’t cleaning up property across the stack.

1 Like
3

It might be worth giving this PR a rebase and a run on CI as well? It is replacing it all using library psutils which is supposed to be a library that handles these shutdown OS agnostically (at least it promises to do that)

Anyone has experience working with this library?