Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: Do not propagate signal to child process
516 views
Skip to first unread message
Kaz Kylheku
Jul 4, 2014, 11:09:13 AM7/4/14
to
On 2014-07-04, Smita Gaikwad <smitaga...@gmail.com> wrote:
> I have one program parent.c as follows:
The topic of signal semantics of C programs on Unix is much better suited to
the comp.unix.programmer newsgroup than comp.unix.admin.
> And executed binary parent. If i send signal SIGINT(ctrl+c) to parent, that
> signal is propagated to child process and it terminates.
That is correct. The TTY-generated SIGINT goes to every process in the
foreground process group, regardless of how they are related together by
parent/child relationships.
> I don't want to
> propagate signal to child process what can i do. Please note in my project i
> don't have access to child.c i can't modify it and there could be many such
> binary which i need to execute through popen this is just sample program.
There are bunch of things you can try.
1. Take advantage of the fact that, in the exec family of system calls,
signals which are set to the SIG_IGN disposition (ignored)
stay in the SIG_IGN disposition in the new image.
This means that you can fork the child process. Then in the child
process set SIGINT to SIG_IGN, and then exec the child executable.
2. You can remove the child process from the process group of the
tty session before execing the child executable.
If that program is to keep running, then it logically isn't part
of the tty session any more. It should close the tty, and create
its own session, like a daemon.
Approach 1 will only work if the child process does not manipulate its signals.
For example if the child happens to run code which iterates over signals and
sets everything to SIG_DFL, then that will defeat the approach.
> I have one program parent.c as follows:
The topic of signal semantics of C programs on Unix is much better suited to
the comp.unix.programmer newsgroup than comp.unix.admin.
> And executed binary parent. If i send signal SIGINT(ctrl+c) to parent, that
> signal is propagated to child process and it terminates.
That is correct. The TTY-generated SIGINT goes to every process in the
foreground process group, regardless of how they are related together by
parent/child relationships.
> I don't want to
> propagate signal to child process what can i do. Please note in my project i
> don't have access to child.c i can't modify it and there could be many such
> binary which i need to execute through popen this is just sample program.
There are bunch of things you can try.
1. Take advantage of the fact that, in the exec family of system calls,
signals which are set to the SIG_IGN disposition (ignored)
stay in the SIG_IGN disposition in the new image.
This means that you can fork the child process. Then in the child
process set SIGINT to SIG_IGN, and then exec the child executable.
2. You can remove the child process from the process group of the
tty session before execing the child executable.
If that program is to keep running, then it logically isn't part
of the tty session any more. It should close the tty, and create
its own session, like a daemon.
Approach 1 will only work if the child process does not manipulate its signals.
For example if the child happens to run code which iterates over signals and
sets everything to SIG_DFL, then that will defeat the approach.
Smita Gaikwad
Jul 8, 2014, 1:50:41 AM7/8/14
to
> There are bunch of things you can try.
>
>
>
> 1. Take advantage of the fact that, in the exec family of system calls,
>
> signals which are set to the SIG_IGN disposition (ignored)
>
> stay in the SIG_IGN disposition in the new image.
>
Your program generally should not ignore signals that represent serious events or that are normally used to request termination. You cannot ignore the SIGKILL or SIGSTOP signals at all. You can ignore program error signals like SIGSEGV, but ignoring the error won't enable the program to continue executing meaningfully. Ignoring user requests such as SIGINT, SIGQUIT, and SIGTSTP is unfriendly.
Kaz Kylheku
Jul 8, 2014, 11:10:14 AM7/8/14
to
On 2014-07-08, Smita Gaikwad <smitaga...@gmail.com> wrote:
> executing meaningfully. Ignoring user requests such as SIGINT, SIGQUIT, and
> SIGTSTP is unfriendly.
Yes; well that is your requirement. You want a process that is within a
> executing meaningfully. Ignoring user requests such as SIGINT, SIGQUIT, and
> SIGTSTP is unfriendly.
TTY session to ignore Ctrl-C. This is reasonably achieved by ignoring or
blocking SIGINT.
Noninteractive programs such as daemons are not connected to a terminal,
and so do not expect to receive SIGINT; it's perfectly okay to block SIGINT
in such a "deeply backgrounded" process. So it's a matter of: do you regard
that child process to be something that is permanently detached from the
interactive TTY session? (For instance, should it continue running even
if the user closes the TTY session and logs out?)
The kill utility generates the SIGTERM signal (by default, when not given
a signal argument). SIGTERM is the main *non-interactive* way to request
the termination of a process. If you don't block SIGTERM, then the process
can be killed with "kill <pid>".
Smita Gaikwad
Jul 11, 2014, 1:29:16 AM7/11/14
to
>
> There are bunch of things you can try.
>
>
>
> 1. Take advantage of the fact that, in the exec family of system calls,
>
> signals which are set to the SIG_IGN disposition (ignored)
>
> stay in the SIG_IGN disposition in the new image.
>
0 new messages