sending a signal with kill

Signals do not only come from the kernel or the keyboard — one process can deliberately send a signal to another. The tool for this has an unfortunately scary name: kill. Despite the name, kill is just 'send a signal', and most signals do not kill anything. The name is a historical accident from the era when the default signal terminated the target.

On the command line, kill 1234 sends SIGTERM to the process with PID 1234 (a polite request to shut down). kill -9 1234 or kill -KILL 1234 sends SIGKILL (the unstoppable destroy). kill -SIGUSR1 1234 sends a user-defined signal. There is also kill -0 1234, which sends no signal at all but checks whether you are allowed to signal that process and whether it exists — a handy 'is it alive?' probe. In C the underlying call is kill(pid_t pid, int sig); a process can signal itself with raise(sig). Special pid values do more: kill(-pgid, sig) signals a whole process group, which is exactly how Ctrl-C reaches every process in a pipeline at once.

There is a permission rule: you can normally only signal processes you own (same user), or anything if you are root — otherwise kill() fails with EPERM. The honest framing: sending a signal is a blunt instrument. It tells the target 'this condition happened' but you cannot attach data, you cannot be sure the target handled it (it may have ignored or blocked the signal), and you cannot easily tell whether it finished reacting. For rich, reliable communication, signals are the wrong tool — use a pipe, socket, or message queue. Signals are for control and notification: stop, reload, shut down, 'your child died'.