0

As the title states I would like a to be able to send a signal, alert, message, or something to a C++ program while it is executing from a bash script. I have seen some solutions where a script will start the program with arguments, but I need it to occur while the program is already up and running. Is there any way to do that? Basically while the script runs in the background if an error occurs I would like it to be reported to the program directly, rather than be logged somewhere in the OS. I am using Redhat 8.

Thank you

3
  • I believe that's what the "kill"command is for. Just don't send signal 9 to your program. Commented Nov 9, 2021 at 21:27
  • @GerardH.Pille That's what I saw when I was doing some research. I saw that there are two user-defined signals, SIGUSR1 and SIGUSR2. When I run the command kill -10 <PID> the program still closes. Do you know if/how I repurpose them for my own use? Commented Nov 9, 2021 at 21:37
  • One issue is that a signal only conveys one bit of information: "something happened somewhere". There are maybe 30 different SIGRT... signals you might use without intruding on the standard ones. Then I thought of two ways to send messages with signals: (a) Morse code, USR1 for dot, USR2 for dash; (b) Using specific time intervals to represent data. Both very bad ideas. Proper answer added anyway. Commented Nov 10, 2021 at 15:17

2 Answers 2

1

To send signal:

kill -s signal -- pid_of_your_app

signal - Is the signal to send. It may be given as a name or a number.

To send data:

echo "text_message" | your_app

or

cat file | your_app

| - Is pipe, it will send stdout of one command to stdin of your program

Update:

About signal handling, you app needed to handle the signal, because by default it will just exit (you can assign handler for any signall except kill(9)) https://en.cppreference.com/w/cpp/utility/program/signal

#include <csignal>
void signal_handler(int signal);
// Install a signal handler
std::signal(SIGINT, signal_handler);
1
0

You can adapt the receiving program to create a fifo (named pipe) with a well-known path name when it starts, and to remove that fifo when it exits. Typically, you have the receiver also open the same fifo for writing, which keeps it open: pipes without a writer tend to notify EOF to the readers.

Periodically, it can poll the fifo for data, without getting stuck waiting when there is none. I don't do C++, but in C you just mark the fifo O_NONBLOCK -- C++ will have some similar mechanism.

Any other process can then check if the fifo exists (so it knows there is an active reader), and send some text to it which the receiver will understand.

If you prefer threading to blocking, you can have a separate thread to read a blocking fifo, and do the synchronisation within the thread mechanism.

One issue with signals is that you need to identify the pid of the recipient. Using a fifo provides a stable naming method.

Edit: Prototyped a design solution that allows any number of clients to send messages to a server via a named pipe, with reliable startup and closedown conditions. Downside is, it's in Bash: client 40 lines, server 65 lines.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .