signal propagation from boost::process to boost::child

Question

I am using boost::process v. 1.65.1 in a master application for Linux to create few boost::process::child objects and manage data exchanged via boost::process::std_in and boost::process::std_out i.e. pipes.

When my master application receives a CTRL-C sent by console, I see that the child as well do receive a CTRL-C signal.

To terminate my child I'd prefer to send a clear command via pipe, but when I do this the signal has been propagated already. Actually Some child sees the command other do not and see the signal.

Is this signal propagation the normal behavior?
What I can do to prevent this to happen so that I can issue my command via pipe without interference?

score 2 · Answer 1 · answered Apr 11 '18 at 12:42

Is this signal propagation the normal behavior?

It's not propagation per se, it's that when you type Ctrl+C in a POSIX terminal, the SIGINT signal is broadcast to all processes of the terminal's foreground process group. Process groups are managed by the shell and by default forked processed remain in the group of the parent (source).

What I can do to prevent this to happen so that I can issue my command via pipe without interference?

Intercept SIGINT in the child and perform the necessary cleanup:

#include <boost/asio/signal_set.hpp>
#include <iostream>

void exit_handler(const boost::system::error_code&, int signal_number)
{
  std::cerr << "Signal " << signal_number << "!\n";
  exit(1);
}

int main()
{
  boost::asio::io_service io_service;

  boost::asio::signal_set signals(io_service, SIGINT);

  signals.async_wait( exit_handler );

  io_service.run();
}

It's probably a good idea to think about other signals as well (HUP, TERM).

thanks for your response. In true I have 2 issue. The first is that. I want my app to exit on a command received via pipe, so probably in that signal handler I should not call std::exit. The second one, which is the bigger, is the that I am using linux 'poll' to read from console. If I do like you say the 'polling', which is supposed to read the STOP command, returns on signal and doesn't do the read. What can I do for this case? Do you think that signal masking could be an option? I never used them but I understood that prevents the signal to be completely ignored. — Abruzzo Forte e Gentile, Apr 12 '18 at 11:30
@rustyx does that apply to windows CMD as well? Because I observe the behavior similar to that in the question on Windows as well — wcobalt, May 17 '23 at 17:34

signal propagation from boost::process to boost::child

1 Answers1