Nodes ignore Ctrl-C when using Opensplice on Windows
See original GitHub issueBug report
Required Info:
- Operating System:
- Windows (Server) 10
- Installation type:
- Binary fat archive
- Version or commit hash:
- DDS implementation:
- ADLink Opensplice
- Client library (if applicable):
- rclpy
Steps to reproduce issue
Run any Python node
ros2 run demo_nodes_py talker
Then, attempt to Ctrl-C it.
Expected behavior
Process acknowledges that it received a signal and terminates gracefully
Actual behavior
Process ignores the signal entirely and can’t be killed.
Additional Information
I’ve reproduced this phenomenon with Python talkers, listeners and both action clients and servers, so I’d be inclined to think it’s something about rclpy
signal handling. Also, we’ve recently made some changes to it to better support Opensplice precisely (see https://github.com/ros2/rclpy/pull/338).
Issue Analytics
- State:
- Created 4 years ago
- Reactions:1
- Comments:21 (15 by maintainers)
Top Results From Across the Web
ROS 2 Dashing Diademata (codename 'dashing'; May 31st ...
Components are now the recommended way to write your node. ... [ros2/rclpy#360] rclpy nodes ignore ctrl-c when using OpenSplice on Windows.
Read more >CTRL+C and CTRL+BREAK Signals - Windows Console
When SetConsoleCtrlHandler is called with NULL and TRUE values for its parameters, the calling process ignores CTRL+C signals.
Read more >THE ROBOT OPERATING SYSTEM IN TRANSITION
to ROS2, how to use Visual Studio to debug a ROS2 program running on Windows, and how to run either ROS1 or ROS2...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
@nuclearsandwich there’s nothing else to be done here, I’ll take this issue out of the Dashing Patch Release 4 project.
To complicated it further though, I think the Python signal handler is protected in this fashion already, though we do have something in the C extension for rclpy which might be at issue.