SIGINT handler doesn't affect std::process::Command?


I have a simple worker that performs command line commands when it receives tasks. I want to implement a SIGINT handler that continues the current task, and stops directly after. I now have the handler in place using the ctrlc crate, but when I press CTRL+C, the command that is executed is also directly receiving a SIGINT, causing the console command to be effectively killed before finishing successfully.


How can I prevent that the command line commands that I execute with std::process::Command are not affected by the SIGINT which I catch in my main loop?


So, job control in shells specifies that Ctrl-C sends SIGINT to all processes of the foreground job.

You'll need to ensure that the process you spawn handles SIGINT appropriately. If you can't do that because you don't control the executable then I think you'll need to fiddle around with process groups, or daemonise and communicate over a pipe, or other such faffing.

Ok, so if I understand correctly it is not possible to fully "trap" the SIGINT in my application if it executes console commands? And that the console commands that are being executed by my application need to "trap" the SIGNINT separately as well?

In my situation this is possible, as I control the console commands that are being executed, but having to implement signal handlers there separately seems weird to me from an application point of view...

Yes, all processes in a single job get the SIGINT signal at the same time.

Thanks, I've fixed the issue on the console command side and now it works.

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.