
Here's a preview from my zine, Bite Size Linux!! If you want to see more comics like this, sign up for my saturday comics newsletter or browse more comics!

read the transcript!
If you’ve ever used kill you’ve used signals
person, angrily: DIE!!!
process, sad: okay
the Linux kernel sends processes signals in lots of situations
- your child terminated
- the timer you set expired
- that pipe is closed
- illegal instruction
- segmentation fault
you can send signals yourself with the kill system call or command
SIGINT Ctrl-C
SIGTERM kill
SIGKILL kill -9
SIGHUP kill -HUP
(various levels of “die”)
SIGHUP
is often interpreted as “reload config”, e.g. by nginx.
Every signal has a default action, which is one of:
- ignore
- kill process
- kill process AND make core dump file
- stop process
- resume process
Your program can set Custom handlers for almost any signal
person: SIGTERM
(terminate)
process: okay! I’ll (clean up and then exit!
exceptions:
SIGSTOP
& SIGKILL
can’t be ignored
dead program: got SIGKILL
ed
Signals can be hard to handle correctly since they can happen at ANY time
process: handling a signal
person: SURPRISE! another signal!
Saturday Morning Comics!
Want another comic like this in your email every Saturday? Sign up here!