Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Ctrl+Z stops the job whereas Ctrl+C kills the job.

Why is that? Wouldn't the other way make more sense?

z@z-lap:~$ sleep 100&
[1] 4458
z@z-lap:~$ sleep 200&
[2] 4459
z@z-lap:~$ jobs
[1]-  Running                 sleep 100 &
[2]+  Running                 sleep 200 &
z@z-lap:~$ fg %1
sleep 100
[1]+  Stopped                 sleep 100
z@z-lap:~$ jobs
[1]+  Stopped                 sleep 100
[2]-  Running                 sleep 200 &
z@z-lap:~$ fg %1
sleep 100
z@z-lap:~$ jobs
[2]+  Running                 sleep 200 &
share|improve this question
"Wouldn't the other way make more sense?" Could you specify why you think it would? – glglgl Jun 8 '14 at 19:21
up vote 21 down vote accepted

I think you may be confused about the job control notation. Notably "Stopped" means that a job is still alive but that its ability to process anything has been held (it is not given any time on the CPU to process anything). This is effectively a 'Pause' or 'Suspended' state, although that is not the correct technical term.

  • CtrlC does not "stop" a job, it cancels or kills it. Technically it causes an interrupt signal to be sent to the program telling it to abort what it is doing and exit immediately. Some programs will hear this signal and do some emergency clean up work on themselves before exiting. Others will not respond to the signal and are subsequently just aborted.

  • CtrlZ, on the other hand, "stops" a job. Again this is done with a signal, but this time it is a 'stop' instead of an 'interrupt' signal. This effectively puts it on hold and returns control to the shell, but does not actually kill the job. If you would like such a job to keep running, you can then issue a bg command to send the last stopped job to the background. It will then continue running as a background job as if you had run it with & in the first place. You may also use fg to resume the last stopped job in the foreground (allowing it to continue where it left off, and allowing you to interact with it again).

share|improve this answer
I still think that Ctrl+Z will send SIGKILL and Ctrl+C sends SIGINIT. So the Ctrl+Z would also kills the job. But from my example Ctrl+Z only Stops the job like you said. So it make me a little confused. – neo0 Jun 8 '14 at 7:58
@neo0 - maybe you're used to some weird custom setup? You can configure that stuff - though you probably shouldn't in case you have an application that relies on those maps. But the default configuration is CTRL+C=SIGINT and CTRL+Z=SIGTSTP. – mikeserv Jun 8 '14 at 8:17
Caleb is right (+1). The ctrl-Z stops the program, which you should regard as "freezing" it, but that program still is in memory, it's files opened, etc. It is not killed/terminated. – Olivier Dulac Jun 8 '14 at 8:23
"Suspend" might be clearer than "stop". – Russell Borogove Jun 8 '14 at 16:43
@Russell If you were architecting UNIX from scratch today maybe you would us that but the signal is a stop signal and the guy's shell is telling him the job is stopped--hence my choice to use that term but explain what it means in context. – Caleb Jun 8 '14 at 18:45

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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