These signals are used to support job control. If your system doesn't support job control, then these macros are defined but the signals themselves can't be raised or handled.
You should generally leave these signals alone unless you really understand how job control works. See Job Control.
The default action for this signal is to ignore it. If you establish a handler for this signal while there are child processes that have terminated but not reported their status via
waitpid(see Process Completion), whether your new handler applies to those processes or not depends on the particular operating system.
You can send a
SIGCONTsignal to a process to make it continue. This signal is special—it always makes the process continue if it is stopped, before the signal is delivered. The default behavior is to do nothing else. You cannot block this signal. You can set a handler, but
SIGCONTalways makes the process continue regardless.
Most programs have no reason to handle
SIGCONT; they simply resume execution without realizing they were ever stopped. You can use a handler for
SIGCONTto make a program do something special when it is stopped and continued—for example, to reprint a prompt when it is suspended while waiting for input.
SIGSTOPsignal stops the process. It cannot be handled, ignored, or blocked.
SIGTSTPsignal is an interactive stop signal. Unlike
SIGSTOP, this signal can be handled and ignored.
Your program should handle this signal if you have a special need to leave files or system tables in a secure state when a process is stopped. For example, programs that turn off echoing should handle
SIGTSTPso they can turn echoing back on before stopping.
This signal is generated when the user types the SUSP character (normally C-z). For more information about terminal driver support, see Special Characters.
A process cannot read from the user's terminal while it is running as a background job. When any process in a background job tries to read from the terminal, all of the processes in the job are sent a
SIGTTINsignal. The default action for this signal is to stop the process. For more information about how this interacts with the terminal driver, see Access to the Terminal.
This is similar to
SIGTTIN, but is generated when a process in a background job attempts to write to the terminal or set its modes. Again, the default action is to stop the process.
SIGTTOUis only generated for an attempt to write to the terminal if the
TOSTOPoutput mode is set; see Output Modes.
SIGKILLsignals and (obviously)
SIGCONTsignals. The signals are marked as pending, but not delivered until the process is continued. The
SIGKILLsignal always causes termination of the process and can't be blocked, handled or ignored. You can ignore
SIGCONT, but it always causes the process to be continued anyway if it is stopped. Sending a
SIGCONTsignal to a process causes any pending stop signals for that process to be discarded. Likewise, any pending
SIGCONTsignals for a process are discarded when it receives a stop signal.
When a process in an orphaned process group (see Orphaned Process Groups) receives a
signal and does not handle it, the process does not stop. Stopping the
process would probably not be very useful, since there is no shell
program that will notice it stop and allow the user to continue it.
What happens instead depends on the operating system you are using.
Some systems may do nothing; others may deliver another signal instead,
SIGHUP. On GNU/Hurd systems, the process
SIGKILL; this avoids the problem of many stopped,
orphaned processes lying around the system.