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?
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
If a job has been stopped via the SIGSTP signal, then you can truly kill it with the
kill command like so:
$ kill %1
%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 + Stopped sleep 1000 $ jobs + Stopped sleep 1000
Here I've used Ctrl+Z to stop my
sleep 1000 command. In the output the
 corresponds to the
%1 that I mentioned above. Killing it like so would have the same effect as the Ctrl+C.
$ kill %1 + Terminated sleep 1000
bg command that I mentioned above would act on the job that has the plus sign,
+ after its number. Notice it here, in
+ Stopped sleep 1000
It's more obvious if I have a couple of jobs, for example:
$ jobs  Stopped sleep 1000 - Stopped sleep 2000 + Stopped sleep 3000
So any bare
bg command will act on the job with the
+. I can target a specific one like so:
$ fg %1 sleep 1000
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.