(A UN*X signal:)
On Unix, Linux and the other Unixoids, not to mention POSIX.1 beloved of committees, SIGTTIN is the signal delivered to a process which tries to read from its controlling tty when it shouldn't. It is sent to a process which tries to read its /dev/tty while its shell has decided to run it in the background. It doesn't make sense to let more than one process read from the same tty -- where will the characters go?
Instead, all but the controlling process will be signalled that they cannot read from the tty at this time. The default action is thus to suspend the process: it is stopped, but can be resumed by bringing it back to the foreground.
To generate SIGTTIN in the comfort of your own $HOME, try to read from the tty while in the background:
[ariels@HumptyDumpty ~/Tests]$ ( sleep 3 ; cat ) &
[4] 12193
ariels@HumptyDumpty ~/Tests$ wait 3 seconds, then...
[4] + Suspended (tty input) ( sleep 3; cat )
ariels@HumptyDumpty ~/Tests$ fg
( sleep 3; cat )
xyzzy
xyzzy
[ariels@HumptyDumpty ~/Tests]$
We create a
child process which will
sleep 3 seconds, then try to
copy standard input, coming from its tty, to
standard output. 3 seconds later, we are notified
(you may need to tell your shell to set notify in order to get process status reports asynchronously) that the process has received
SIGTTIN and has been stopped, as it is waiting for
tty input. Even though we proceed to type at the tty ("fg"), the
shell gets the
characters, not our backgrounded process. As soon as we resume the process, it can read tty input -- and proceeds to do so.