1

Related to the Signal manpage:

A child created via fork(2) inherits a copy of its parent's signal dispositions. During an execve(2), the dispositions of handled signals are reset to the default; the dispositions of ignored signals are left unchanged.

In this case it should be totally unrelated if the child process runs in foreground or in background.

Example:

If I start xterm as a child bg process in a shell...

xterm &

...and start a bg process in xterm like

`ls -lR / &`

does the ls process stops when I stop xterm in the shell with

kill -STOP [pid_of_xterm]

?

I guess no, but I don´t know why.

I appreciate your help...

2

A child created via fork(2) inherits a copy of its parent's signal dispositions.

That means that the child handles signals in the same way as its parents: it has the same signal handlers and the same set of ignored signals. This does not mean that sending a signal to the parent somehow also sends a signal to the child (otherwise, killing a process would also kill all of its descendants… ).

A process may be programmed with a signal handler that relays the signal to some or all of its children, but this isn't common. And it can't be done at all for signals that can't be handled such as SIGKILL and SIGSTOP. A rare case where this is done is that interactive shells propagate SIGHUP to running jobs.

In your example, with an ls process which is a child of a shell which is a child of xterm, sending a STOP signal to the xterm process only stops the xterm process. It has no impact on the shell or on ls. At some point, ls will block trying to write to the terminal, because the terminal isn't reading the data. What this means is that the write system call in the ls process will take a long time, this has nothing to do with signals.

There's a way to deliver a signal to a set of processes with parent-child relationships, but it's a decision by the caller, not by the recipient of the signal, and the set of processes has to be a process group. The purpose of process groups is to be able to send a signal to a whole shell job, even if that job consists of multiple processes (e.g. a pipeline).

  • Mhh... When I continue the process with e.g bg the output continues like the process has been stopped. What I would expect if the ls process continued while xterm has been stopped is that afterwards the unwritten output appears immediately. Why does the writting process alone takes as much time as the ls and writting process? – goulashsoup Nov 25 '16 at 18:28
  • 1
    @goulashsoup ls stops producing output pretty much as soon as xterm is stopped because it's blocked in a write call, trying to write to the terminal. When xterm is resumed, the write system call returns and ls continues doing stuff. – Gilles Nov 25 '16 at 19:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.