Detecting SIGTTIN when a child background process runs "cat" - c

I have the following program where I set the parent's process group and the child's process group, as well as giving the terminal control to the parent. Then, I run "cat" in the "background" child, which is supposed to generate SIGTTIN. However, the printf line in sighandler is not printed. Any ideas how to properly detect SIGTTIN in this case?
void sighandler(int signo){
printf("SIGTTIN detected\n");
}
int main() {
int status;
pid_t pid;
pid = fork ();
setpgid(0,0);
tcsetpgrp (STDIN_FILENO, 0);
signal(SIGTTIN, sighandler);
if (pid == 0)
{
setpgid(0,0);
execl ("cat", NULL);
_exit (EXIT_FAILURE);
}
else{
int status;
setpgid(pid,pid);
waitpid(-1, &status, 0);
}
return status;
}

Mariska,
For Parent Processes
As explained in the Stack Overflow post titled, "Catch Ctrl-C in C,":
The behavior of signal() varies across UNIX versions, and has also
varied historically across different versions of Linux. Avoid its use:
use sigaction(2) instead.
As described in the Linux Programmer's Manual, you should use sigaction():
The sigaction() system call is used to change the action taken by a
process on receipt of a specific signal.
Try this:
#include<stdio.h>
#include <signal.h>
static void handler(int signum)
{
/* Take appropriate actions for signal delivery */
printf("SIGTTIN detected\n");
}
int main()
{
struct sigaction sa;
sa.sa_handler = handler;
sigemptyset(&sa.sa_mask);
sa.sa_flags = SA_RESTART; /* Restart functions if
interrupted by handler */
if (sigaction(SIGINT, &sa, NULL) == -1)
/* Handle error */;
/* Further code */
}
For Child Processes
There are a couple of points you should know when dealing with signal handlers for the child processes:
A forked child inherits the signal handlers from the parent
Because of the above, you need to implement some sort of signal handler for the parent and then change the signal handler before and after executing a child.
As explained in the Linux Programmer's Manual:
All process attributes are preserved during an execve(), except the following:
a. The set of pending signals is cleared (sigpending(2)).
b. The dispositions of any signals that are being caught are
reset to being ignored.
c. Any alternate signal stack is not preserved (sigaltstack(2)).
Thus, the exec() functions do not preserve signal handlers.
From the above, I am trying to show you that pressing Ctrl-C sends the signal to the parent process (unless you use exec()), and then the signals are automatically propagated to children. This is why we need to change the signal handler. Even when the child is currently "active", the parent will still receive signals before the child will.
Please let me know if you have any questions!

Related

master error when multiple signal are sent

I got this issue:
I made a program in c, where the main process creates some child process, and these, after a while, are able to send a signal to the main process:
the signal is sent with this code:
kill(getppid(), SIGUSR1);
and the main process, in the while loop is waiting the SIGUSR1 message...
everything is fine, but if I increase the child number and automatically the possibility to have more signals in the same time, the program crash printing the message:
User defined signal 1
the main code is like this:
void signalHandler(int sig, siginfo_t* info, void* vp) {
if (sig == SIGUSR1) {
printf("SIGUSR1 has arrived\n");
} else if (sig == SIGUSR2) {
printf("SIGUSR2 has arrived\n");
}
}
int main(int argc, char const *argv[]) {
struct sigaction action, old_action;
memset(&action, 0, sizeof(struct sigaction));
action.sa_sigaction = signalHandler;
sigemptyset(&action.sa_mask);
action.sa_flags = SA_RESTART | SA_NODEFER;
while (1) {
sigaction(SIGUSR1, &action, &old_action);
sigaction(SIGUSR2, &action, &old_action);
}
}
I think the problem is that the signal is sent when the master is still working on the previous signal...but how can I do to fix this thing
thank you very much
It means that the child is sending the signal before the parent process was able to call sigaction() to configure the signal handler. When this happens, the default signal reaction to SIGUSR1 terminates the program:
SIGUSR1 P1990 Term User-defined signal 1
https://man7.org/linux/man-pages/man7/signal.7.html
However, there are many problems with your code. printf() is not safe to be called inside a signal handler (it's AS-Unsafe as defined by POSIX):
https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/functions/V2_chap02.html#tag_15_04_03
Also, using SA_NODEFER may create nested signals (another signal handler is called while some signal handler is running) but your program does not protect against a flood. Given enough children this will generate a stack overflow. Finally, the main program keeps running a non-stop infinite loop reconfiguring the signals, while it should have configured them only once outside the loop and blocked inside the loop (for example sigwait() or pselect()):
https://man7.org/linux/man-pages/man2/select.2.html
Finally, if you expect to run a large number of children that might flood the parent with signals, then it would be better to use the real time signal generation function (sigqueue()) rather than kill(). The difference is that with sigqueue(), all signals are queued and SA_NODEFER is not necessary to avoid discarding signals while some other signal handler is running:
https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/functions/V2_chap02.html#tag_15_04_02
Final conclusion: the code should be completely rewritten.

Should child processes also be unblocking blocked SIGCHLD signals?

I'm trying to understand how blocking and unblocking signals work and I'm trying to understand the following piece of code. Specifically I am looking at line 28 (commented in the code): int a = sigprocmask(SIG_UNBLOCK, &mask, NULL);, aka where the signal is unblocked in the child.
The textbook I got the code from says that the code uses signal blocking in order to ensure that the program performs its add function (simplified to printf("adding %d\n", pid);) before its delete function (simplified to printf("deleting %d\n", pid);). This makes sense to me; by blocking the SIGCHLD signal, then unblocking it after we perform the add function, we ensure that handler isn't called until we perform the add function. However, why would we unblock the signal in the child? Doesn't that just eliminate the whole point of blocking by immediately unblocking it, allowing the child to delete before the parent adds?
However, the output (described after the code) is identical whether or not I have the line commented out or not, meaning that is clearly not what happens. The textbook states:
"Notice that children inherit the blocked set of their parents, so we must be careful to unblock the SIGCHLD signal in the child before calling execve."
But that still seems to me like the unblocking would result in the handler being called. What exactly does this line do?
void handler(int sig) {
pid_t pid;
printf("here\n");
while ((pid = waitpid(-1, NULL, 0)) > 0); /* Reap a zombie child */
printf("deleting %d\n", pid); /* Delete the child from the job list */
}
int main(int argc, char **argv) {
int pid;
sigset_t mask;
signal(SIGCHLD, handler);
sigemptyset(&mask);
sigaddset(&mask, SIGCHLD);
sigprocmask(SIG_BLOCK, &mask, NULL); /* Block SIGCHLD */
pid = fork();
if (pid == 0) {
printf("in child\n");
int a = sigprocmask(SIG_UNBLOCK, &mask, NULL); // LINE 28
printf("a is %d\n",a);
execve("/bin/date", argv, NULL);
exit(0);
}
printf("adding %d\n", pid);/* Add the child to the job list */
sleep(5);
printf("awake\n");
int b = sigprocmask(SIG_UNBLOCK, &mask, NULL);
printf("b is %d\n", b);
sleep(3);
exit(0);
}
Outputs:
adding 652
in child
a is 0
Wed Apr 24 20:18:04 UTC 2019
awake
here
deleting -1
b is 0
However, why would we unblock the signal in the child? Doesn't that
just eliminate the whole point of blocking by immediately unblocking
it, allowing the child to delete before the parent adds?
No. Each process has its own signal mask. A new process inherits its parent's signal mask, but only in the same sense that it inherits the contents of the parent's memory -- the child gets what amounts to an independent copy. Its modifications to that copy are not reflected in the parent's copy, nor vise versa after the child starts. If this were not the case, then all processes in the system would share a single signal mask.
It is only the parent that must not receive SIGCLD too soon, so only the parent needs to have that signal blocked.
[...] The textbook states:
"Notice that children inherit the blocked set of their parents, so we must be careful to unblock the SIGCHLD signal in the child before
calling execve."
But that still seems to me like the unblocking would result in the
handler being called.
Again, "inherit" in the sense of inheriting a copy, not in the sense of sharing the same mask.
What exactly does this line do?
It unblocks SIGCLD in the child -- again, having no effect on the parent -- in case it being blocked would interfere with the behavior of /bin/date, which the child is about to exec.

SIGTERM signal from parent does not invoke signal handler in child?

I'm writing a program where both the child process and the parent process can send a SIGTERM signal to the child.
The signal handler is something like this:
void custom_signal_handler(int signum, siginfo_t* info, void* ptr) {
if (signum == SIGTERM) {
printf("1\n");
}
else if (signum == SIGCONT) {
printf("2\n");
}
}
(I have simplified the printing in the ifs to keep the code here simpler).
For the SIGCONTsignal - only the parent can call this signal with kill(childPid, SIGCONT). When this is happening, the signal handler for the child prints the "2" as intended.
However, for the SIGTERM signal - both the parent can invoke it by sending kill(childPid, SIGTERM) and the child by calling raise(SIGTERM). The problem is that "1" is printed only when the child raises the SIGTERM signal, but not when the parent calls it.
I have regiestered the signal handler to the child:
// set up signal handler
struct sigaction custom_action;
memset(&custom_action, 0, sizeof(custom_action));
custom_action.sa_sigaction = custom_signal_handler;
custom_action.sa_flags = SA_SIGINFO;
// assign signal handlers
if (0 != sigaction(SIGCONT, &custom_action, NULL)) {
printf("Signal registration failed: %s\n",strerror(errno));
return -1;
}
if (0 != sigaction(SIGTERM, &custom_action, NULL)) {
printf("Signal registration failed: %s\n",strerror(errno));
return -1;
}
Any ideas? Thanks!
In a comment to the question, OP states
I am sending the SIGTERM from the parent while the relevant child is at "raise(SIGSTOP)". I think that because the child is in SIGSTOP it doesn't run the signal handler.
Correct. When a process is stopped, it does not receive signals other than SIGCONT and SIGKILL (plus SIGSTOP, SIGTSTP, SIGTTIN, SIGTTOU are ignored). All other signals should become pending, delivered when the process is continued. (Standard POSIX signals are not queued, though, so you can rely on only one standard POSIX signal becoming pending.)
However, I do need to send the SIGTERM only when the child is in SIGSTOP, without sending SIGCONT before.
The target process will receive SIGTERM only after it is continued. That is how stopped processes behave.
Is there a workaround?
Perhaps; it depends on the requirements. But do note that your intended use case involves behaviour that does not comply with POSIX (i.e., you want a stopped process to react to something other than just being continued or killed outright); and that is the direct reason for the problems you have encountered.
The simplest is to use a variant of SIGCONT instead of SIGTERM, to control the terminating of the process; for example, via sigqueue(), providing a payload identifier that tells the SIGCONT signal handler to treat it as a SIGTERM signal instead (and thus distinguishing between normal SIGCONT signals, and those that are stand-ins for SIGTERM).
A more complicated one is to have the process fork a special monitoring child process, that regularly sends special "check for pending SIGTERM signals" SIGCONT signals, and dies when the parent dies. The child process can be connected to the parent via a pipe (parent having the write end, child the read end), so that when the parent dies, a read() on the child end returns 0, and the child can exit too. The parent process SIGCONT handler just needs to detect if the signal was sent by the child process — the si_pid field of the siginfo_t structure should only match the child process ID if sent by the child —, and if so, check if a SIGTERM is pending, handle it if yes; otherwise just raise SIGSTOP. This approach is very fragile, due to the many possibilities of race windows — especially raising SIGSTOP just after receiving SIGCONT. (Blocking SIGCONT in the signal handler is essential. Also, the monitoring child process should probably be in a separate process group, not attached to any terminal, to avoid being stopped by a SIGSTOP targeted at the entire process group.)
Note that one should only use async-safe functions in signal handlers, and retain errno unchanged, to keep everything working as expected.
For printing messages to standard error, I often use
#include <stdlib.h>
#include <unistd.h>
#include <errno.h>
static int wrerr(const char *msg)
{
const int saved_errno = errno;
const char *end = msg;
ssize_t count;
int retval = 0;
/* Find end of string. strlen() is not async-signal safe. */
if (end)
while (*end)
end++;
while (msg < end) {
count = write(STDERR_FILENO, msg, (size_t)(end - msg));
if (count > 0)
msg += count;
else
if (count != -1) {
retval = EIO;
break;
} else
if (errno != EINTR) {
retval = errno;
break;
}
}
errno = saved_errno;
return retval;
}
which not only is async-signal safe, but also keeps errno unchanged. It returns 0 if success, and an errno error code otherwise.
If we expand the prints a bit for clarity, OP's custom signal handler becomes for example
void custom_signal_handler(int signum, siginfo_t* info, void* context) {
if (signum == SIGTERM) {
wrerr("custom_signal_handler(): SIGTERM\n");
} else
if (signum == SIGCONT) {
wrerr("custom_signal_handler(): SIGCONT\n");
}
}
Do note that when this is used, ones program should not use stderr (from <stdio.h>) at all, to avoid confusion.

C code workks in Mac (Darwin 13.4), but not in Linux (2.6.32)

I'm writing a toy shell program for a class and I did all of my coding on my mac (Darwin 13.4.0) and compiled using gcc <programname> -o <executablename>. Everything seems to run perfectly. Then I ftp the source code over to the school's Linux server and compile again, using the exact same compilation instruction, but on the Linux machine the code is buggy. In particular, the sigaction (signal handler) doesn't seem to be working properly all the time. It seems as though it isn't reliably catching the SIGCHLD signal. Edit--Actually, what was happening was the variable I was storing the status in was getting clobbered, so the incorrect status was displayed for foreground processes.
Anyone have any ideas why the change in OS might cause this kind of problem?
Here's what my signal handler code looks like:
void handleSignal(int signal){
int childid = 0;
int tempStatus = 0;
while ( (childid = waitpid(-1, &childStatus, WNOHANG)) > 0) {
/*Parse the exit status */
if(WIFEXITED(childStatus)){
childStatus = WEXITSTATUS(childStatus);
}
switch (signal) {
/*if the signal came from a child */
case SIGCHLD:
/*for background processes alert user */
if (childid != foregroundProcess){
printf("pid %i terminated:",childid);
showStatus(childStatus);
fflush(stdout);
}
/* for foreground children ending, just set the temp Status, in case*/
/* background children also need to be caught */
else {
tempStatus = childStatus;
}
break;
case SIGINT:
/*If there is a foreground child, send signal to it, else ignore. */
if (foregroundProcess){
kill(foregroundProcess, signal);
}
break;
default:
printf("Some other signal was received: code %i\n", signal);
fflush(stdout);
}
}
childStatus = tempStatus; /* reset child status to foreground status */
}
Edit: Adding the code that registers the signal handler:
struct sigaction sa;
sa.sa_handler = &handleSignal; /*passing function ref. to handler */
sa.sa_flags = SA_RESTART; /* restart the shell signal handler */
sigfillset(&sa.sa_mask); /*block all other signals while handling sigs */
sigaction(SIGINT, &sa, NULL);
sigaction(SIGCHLD, &sa, NULL);
sigaction(SIGTERM, &sa, NULL);
Disregard. Solved it. Here's what the problem was: I was waiting on the foreground child process in the main program loop, and I was also waiting on it in the signal handler. In the main loop I was using waitoptions = 0, so the program would wait, and in the handler WNOHANG.
So why did it behave differently in Linux versus Darwin? Here's my theory: On the Darwin box, when the child died, the SIGCHLD signal was being delivered and handled before the waitpid in the parent's main loop caught that the child had died. So the signal handler handled the dying foreground child. Then, when execution returned to the waitpid command in the main loop, there was no child with that pid, and the waitpid function returned with an error of -1. However, I wasn't checking the return value of that waitpid call, which meant that the error was silent to me, and the program operated correctly on the Darwin machine.
In the Linux machine, however, the waitpid in the main program loop executed first before the signal handler. So childstatus would be set (correctly) in the main program loop. Then, when it came time for the signal handler to catch the SIGCHLD signal, the process had already been waited on. So waitpid returned error (-1, errno 10). But because of how I handled the child status variable in the signal handler, (with childStatus and tempStatus) this situation would clobber my child status, resetting it back to 0. So every foreground child showed an exit status of 0 when run on the Linux machine, but an appropriate exit status on the Mac. The solution? Change the tempStatus declaration to int tempStatus = childStatus. That way, if the childStatus has already be set by a foreground process, the entire loop is skipped and the status persists. If the signal handler is called on behalf of a background process, however, the signal handler saves the foreground status, if it exists, and displays the background status as it handles the background, and then resets the foreground status.
Ugly... but it will work for well enough for a grade in a couple of hours.
I don't know if any of this will ever help anyone else, but hey, it might. Talk about frustrating!

ctrl-c killing my background processes in my shell [duplicate]

I have one simple program that's using Qt Framework.
It uses QProcess to execute RAR and compress some files. In my program I am catching SIGINT and doing something in my code when it occurs:
signal(SIGINT, &unix_handler);
When SIGINT occurs, I check if RAR process is done, and if it isn't I will wait for it ... The problem is that (I think) RAR process also gets SIGINT that was meant for my program and it quits before it has compressed all files.
Is there a way to run RAR process so that it doesn't receive SIGINT when my program receives it?
Thanks
If you are generating the SIGINT with Ctrl+C on a Unix system, then the signal is being sent to the entire process group.
You need to use setpgid or setsid to put the child process into a different process group so that it will not receive the signals generated by the controlling terminal.
[Edit:]
Be sure to read the RATIONALE section of the setpgid page carefully. It is a little tricky to plug all of the potential race conditions here.
To guarantee 100% that no SIGINT will be delivered to your child process, you need to do something like this:
#define CHECK(x) if(!(x)) { perror(#x " failed"); abort(); /* or whatever */ }
/* Block SIGINT. */
sigset_t mask, omask;
sigemptyset(&mask);
sigaddset(&mask, SIGINT);
CHECK(sigprocmask(SIG_BLOCK, &mask, &omask) == 0);
/* Spawn child. */
pid_t child_pid = fork();
CHECK(child_pid >= 0);
if (child_pid == 0) {
/* Child */
CHECK(setpgid(0, 0) == 0);
execl(...);
abort();
}
/* Parent */
if (setpgid(child_pid, child_pid) < 0 && errno != EACCES)
abort(); /* or whatever */
/* Unblock SIGINT */
CHECK(sigprocmask(SIG_SETMASK, &omask, NULL) == 0);
Strictly speaking, every one of these steps is necessary. You have to block the signal in case the user hits Ctrl+C right after the call to fork. You have to call setpgid in the child in case the execl happens before the parent has time to do anything. You have to call setpgid in the parent in case the parent runs and someone hits Ctrl+C before the child has time to do anything.
The sequence above is clumsy, but it does handle 100% of the race conditions.
What are you doing in your handler? There are only certain Qt functions that you can call safely from a unix signal handler. This page in the documentation identifies what ones they are.
The main problem is that the handler will execute outside of the main Qt event thread. That page also proposes a method to deal with this. I prefer getting the handler to "post" a custom event to the application and handle it that way. I posted an answer describing how to implement custom events here.
Just make the subprocess ignore SIGINT:
child_pid = fork();
if (child_pid == 0) {
/* child process */
signal(SIGINT, SIG_IGN);
execl(...);
}
man sigaction:
During an execve(2), the dispositions of handled signals are reset to the default;
the dispositions of ignored signals are left unchanged.

Resources