I have suspend a process through kill -TSTP <pid>. Then tried to continue it with kill -CONT <pid>. But After completion of process, control is not returning to bash. Why this is happening? And what to do to overcome this problem?

I started the process (a shell script) from one bash (say bash-1) with ./name.sh. Then suspended that process with the command kill -TSTP <pid> through bash-2. Finally tried to resume it with kill -CONT <pid> through bash-2. But after completion of shell script, control is not returning, it just staying there forever.

  • 1
    We need more information here. Are you starting the process from bash? Are you backgrounding the process or running straight in the foreground? Does the process indeed complete successfully? Some processes are sensitive to stopping (when timeouts and such are involved). Is the process still waiting on something? What's the ps output? Is the process gone? If not, what's its state? Is maybe just echo disabled? Try stty echo + enter. – orion Apr 7 '16 at 9:43
  • Yes, started the process (a shell script) from one bash (say bash-1) with "./name.sh". Then suspended that process with the command "kill -TSTP <pid>" through bash-2. Finally tried to resume it with "kill -CONT <pid>" through bash-2. But after completion of shell script, control is not returning, it just staying there forever. – Shamindra Parui Apr 7 '16 at 11:41

Process started from a shell have a controlling TTY associated with them that they inherit from the shell and also belong to a process group. When running multiple processes in a pipe with | or using subshell notation with ()'s, all those processes are started with the same process group. When the user hit's the suspend keystroke, normally Ctrl-Z from the keyboard, the TTY layer sends the SIGTSTP signal to all processes in the current foreground process group and the parent shell wakes up with a SIGCHLD (or returns from it's call to wait()) to handle the TTY again. The shell is responsible for controlling which process group is in the foreground for it's controlling TTY and the shell itself resides in it's own process group.

If a process is not part of the current, foreground process group for the TTY, it will be stopped automatically by the TTY layer with a SIGTTIN if it tries to read from the terminal. For example, sending SIGCONT to an interactive text editor like vim will resume it, but it will immediately get a SIGTTIN as soon as it call's read() to get the next keypress from the keyboard. The shell must be notified with the fg job control directive that it should move vim to the foreground process group before resuming it thereby removing the shell from being in the foreground.


You should have stopped your process with kill -STOP, not kill -TSTP.

The former is designed to support suspending/resuming a process just with signals so kill -CONT would have produced the expected result while the latter (SIGTSTP) is more designed to support job control.

The interactive shell that launched your stopped script is able to revive it through the fg command. fg does extra things before eventually resuming the process with SIGCONT. Sending the signal alone isn't enough.

  • Both of your basic claims are wrong. The only difference between STOP and TSTP is that TSTP is automatically generated by the tty driver in some cases. Every process with the same credentials is permitted to resume a process. – schily Apr 7 '16 at 22:50
  • @schily Thanks for your downvote and constructive comments. Every process with the required privileges is indeed permitted to resume a stopped process, that's the reason why the OP didn't ask any question in the first place. – jlliagre Apr 7 '16 at 23:17

kill -CONT is something that is not understood by the shell.

For this reason, it just continues the process without any effect to the shell.

This results in something similar to a background process.

If you like to continue a process, better call fg or if this is not the "current job", use jobs to list all current jobs and then call e.g. fg %3 if the job in question is job #3.

Note that the difference between calling kill -CONT and fg from the launching shell is that with fg, the shell in addition to sending the SIGCONT signal sets the tty process group to the process group of the resumed process. The setting of the tty process group controls the automated delivery of the signals TSTP, TTIN and TTOU. Later the shell starts to wait for the command.

If you however called kill -CONT from a different shell/tty than the one where the process in question runs, then it should be really obvious that you just continue a foreign process. The shell that fired the kill -CONT will just return to it's prompt, but you see this.

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.