Two great signals: SIGSTOP and SIGCONT

major@mhtx.net (Major Hayden) — Mon, 15 Jun 2009 18:16:19 +0000

The best uses I’ve found for the SIGSTOP and SIGCONT signals are times when a process goes haywire, or when a script spawns too many processes at once.

You can issue the signals like this:

kill -SIGSTOP [pid]
kill -SIGCONT [pid]

Wikipedia has great definitions for SIGSTOP:

When SIGSTOP is sent to a process, the usual behaviour is to pause that process in its current state. The process will only resume execution if it is sent the SIGCONT signal. SIGSTOP and SIGCONT are used for job control in the Unix shell, among other purposes. SIGSTOP cannot be caught or ignored.

and SIGCONT:

When SIGSTOP or SIGTSTP is sent to a process, the usual behaviour is to pause that process in its current state. The process will only resume execution if it is sent the SIGCONT signal. SIGSTOP and SIGCONT are used for job control in the Unix shell, among other purposes.

In short, SIGSTOP tells a process to “hold on” and SIGCONT tells a process to “pick up where you left off”. This can work really well for rsync jobs since you can pause the job, clear up some space on the destination device, and then resume the job. The source rsync process just thinks that the destination rsync process is taking a long time to respond.

In the ps output, stopped processes will have a status containing T. Here’s an example with crond:

# kill -SIGSTOP `pgrep crond`
# ps aufx | grep crond
root 3499 0.0 0.0 100328 1236 ? Ts Jun11 0:01 crond
# kill -SIGCONT `pgrep crond`
# ps aufx | grep crond
root 3499 0.0 0.0 100328 1236 ? Ss Jun11 0:01 crond

Sigcont on Major Hayden

Two great signals: SIGSTOP and SIGCONT