1

People often hit Ctrl + c or Ctrl + z to cancel or abandon the job if the process gets sluggish, in this case which of these signals get processed, the first one or the last one? is each signal processed? if not, then which ones are ignored?

1

The signals are sent in the order that you type them via the terminal to the kernel. If you use Ctrl+C you're instructing the kernel to send the signal SIGINT, to the foreground process group. Upon receiving this, the command that was running will be terminated.

With a Ctrl+Z you're sending the signal SIGSTP. Which doesn't actually kill the process, just tells it to stop, temporarily. When this is used you can resume the process, by telling the shell to bring it back to the foreground, via the fg command, or you can background it with the bg command.

If a job has been stopped via the SIGSTP signal, then you can truly kill it with the kill command like so:

$ kill %1

Where %1 is the job id of the job you just SIGSTP'd.

Checking on stopped jobs

You can use the job command to see what job's have been stopped in a shell like so:

$ sleep 1000 
^Z
[1]+  Stopped                 sleep 1000
$ jobs
[1]+  Stopped                 sleep 1000

Here I've used Ctrl+Z to stop my sleep 1000 command. In the output the [1] corresponds to the %1 that I mentioned above. Killing it like so would have the same effect as the Ctrl+C.

$ kill %1
[1]+  Terminated              sleep 1000

The fg and bg command that I mentioned above would act on the job that has the plus sign, + after its number. Notice it here, in jobs output:

[1]+  Stopped                 sleep 1000

It's more obvious if I have a couple of jobs, for example:

$ jobs
[1]   Stopped                 sleep 1000
[2]-  Stopped                 sleep 2000
[3]+  Stopped                 sleep 3000

So any bare fg or bg command will act on the job with the +. I can target a specific one like so:

$ fg %1
sleep 1000
  • 1
    It's not the shell sending the signal, it's the kernel (upon receiving that character from the terminal). Note that those signals are sent to the foreground process group (job), not necessarily a single process. SIGINT or SIGTERM (sent by kill) are not guaranteed to terminate a process as it can be intercepted or ignored or blocked by the process. – Stéphane Chazelas Aug 21 '14 at 6:38
  • @StéphaneChazelas - thanks, I'll fix that. – slm Aug 21 '14 at 6:39
2

If the recipient has time to start processing a signal before the next one comes, then all the signals will be handled in order.

When a process receives a signal but isn't ready to handle it (e.g. the signal is masked, or the process is stopped), the kernel marks the signal as pending. The signal will be delivered.

If multiple signals of different numbers are received while the process isn't ready, then all the signals will be handled. The signals are delivered to the process one by one. The order in which they are delivered is left unspecified by POSIX; on Linux, they are delivered by number, smallest first (so e.g. SIGHUP=1 will be delivered first if pending, then SIGQUIT=2, etc.); FreeBSD makes no guarantee.

If multiple signals with the same number are received while the process isn't ready, these signals may be merged. POSIX doesn't specify what happens but most unices do merge. For example, if you run kill -1 234; kill -1 234, then whether process 234's handler for signal 1 is received once or twice is a matter of timing, it depends whether 234 gets a time slice in which the first signal is delivered.

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.