So apps quitting due to a caught signal is often expected behavior. Hitting Ctrl-C while a terminal script is running is an example of a signal that didn't get trapped.
I guess I didn't learn too much, because I'd have guessed that that's an example of a signal that DID get trapped, or does
The app can elect to ignore most signals that are trying to kill it (by trapping them) also, so they usually "die willingly".
govern?
Saying that a signal was "caught" or "trapped" (somewhat synonymous, since it's a trap that does the catching) means the program set up a special procedure (a trap) to do something special if it receives that signal from another process. If no trap has been set up for that specific type of signal, then the signal "doesn't get caught by a trap", and the system takes the default behavior instead. SIGIO will be ignored. SIGTERM will somewhat softly terminate the process. SIGKILL is referred to as an "uncatchable signal" as there is no trap that can be used to catch it and process it. Processes receiving a KILL signal are removed from the process table, their files are close, and their resources are reclaimed. The process is not given any further opportunity to run, it is halted when its currently running timeslice (if any) is up.
SIGIO is often used for a process to signal to another that it's time to do something - a data file is ready for processing, the io buffer is empty and a process is requesting more data be received and stored in the buffer, etc. SIGTERM is generated by things like CTRL-C, that mean someone is
requesting the process to stop. They're not in a big hurry, it's not urgent. Just finish what you were doing (finish rendering that frame and add it to the outgoing buffer), clean up any mess you've made (delete those temp files), and quit. SIGKILL can leave a mess behind. Files may be in a state of flux, a buffer may be half full or half empty, temp files may be left sitting around, etc. But if the process is stuck, this generally stops it and allows you to run it again if you want to.
Not everything responds immediately to a kill, and some things won't respond at all. It's usually due to something deadlocked in the kernel. A program is trying to read a file, but the hard drive just hung up. It's still spinning but is ignoring the computer's request. The program called an API that wound up in the kernel talking with the hard drive, and it is waiting on the drive to reply to something. It'll hold onto that time slice until at least it gets back to the main program, where it will exit on receiving the kill, but the kernel doesn't know about the kill and will keep waiting on the drive. Maybe forever. It's like you're on the phone with a store, who has you on hold while they look up a price, when someone says hey its time to go get in the car. "I'm on the phone, hang on just a minute..." and the colorful wheel starts to spin. Maybe your transfer got disconnected or something, and no one is ever going to take you off hold, you don't know. If it's not THAT important, COME ON LETS GO and you put down the phone. (kill -9 / siggkill / force quit) Or maybe this is urgent and they are going to be closing for the weekend and you NEED to get an answer today, tough, you're going to have to wait. (the unkillable process) Eventually you get tired of waiting and realize no one is ever coming back to the call and you have no alternative but to just hang up. (reboooooot!)
