4.8. Daemons, Signals, and Killing Processes
Prev | Chapter 4. UNIX Basics | Next

## 4.8. Daemons, Signals, and Killing Processes

When using an editor, it is easy to control the editor and load files because the editor provides facilities to do so, and because the editor is attached to a terminal. Some programs are not designed to be run with continuous user input and disconnect from the terminal at the first opportunity. For example, a web server responds to web requests, rather than user input. Mail servers are another example of this type of application.

These programs are known as daemons. The term daemon comes from Greek mythology and represents an entity that is neither good or evil, and which invisibly performs useful tasks. This is why the BSD mascot is the cheerful-looking daemon with sneakers and a pitchfork.

There is a convention to name programs that normally run as daemons with a trailing “d”. BIND is the Berkeley Internet Name Domain, but the actual program that executes is named(8). The Apache web server program is `httpd` and the line printer spooling daemon is lpd(8). This is only a naming convention. For example, the main mail daemon for the Sendmail application is sendmail(8), and not `maild`.

One way to communicate with a daemon, or any running process, is to send a signal using kill(1). There are a number of different signals; some have a specific meaning while others are described in the application's documentation. A user can only send a signal to a process they own and sending a signal to someone else's process will result in a permission denied error. The exception is the `root` user, who can send signals to anyone's processes.

FreeBSD can also send a signal to a process. If an application is badly written and tries to access memory that it is not supposed to, FreeBSD will send the process the Segmentation Violation signal (`SIGSEGV`). If an application has used the alarm(3) system call to be alerted after a period of time has elapsed, it will be sent the Alarm signal (`SIGALRM`).

Two signals can be used to stop a process: `SIGTERM` and `SIGKILL`. `SIGTERM` is the polite way to kill a process as the process can read the signal, close any log files it may have open, and attempt to finish what it is doing before shutting down. In some cases, a process may ignore `SIGTERM` if it is in the middle of some task that can not be interrupted.

`SIGKILL` can not be ignored by a process. This is the “I do not care what you are doing, stop right now” signal. Sending a `SIGKILL` to a process will usually stop that process there and then.[2].

Other commonly used signals are `SIGHUP`, `SIGUSR1`, and `SIGUSR2`. These are general purpose signals and different applications will respond differently.

For example, after changing a web server's configuration file, the web server needs to be told to re-read its configuration. Restarting `httpd` would result in a brief outage period on the web server. Instead, send the daemon the `SIGHUP` signal. Be aware that different daemons will have different behavior, so refer to the documentation for the daemon to determine if `SIGHUP` will achieve the desired results.

Procedure 4.1. Sending a Signal to a Process

This example shows how to send a signal to inetd(8). The inetd(8) configuration file is `/etc/inetd.conf`, and inetd(8) will re-read this configuration file when it is sent a `SIGHUP`.

1. Find the PID of the process to send the signal to using pgrep(1). In this example, the PID for inetd(8) is 198:

   `%` `pgrep -l inetd` 198 inetd -wW

2. Use kill(1) to send the signal. Because inetd(8) is owned by `root`, use su(1) to become `root` first.

   `%` `su` `Password:` `#` `/bin/kill -s HUP 198`

   Like most UNIX® commands, kill(1) will not print any output if it is successful. If a signal is sent to a process not owned by that user, the message kill: `PID`: Operation not permitted will be displayed. Mistyping the PID will either send the signal to the wrong process, which could have negative results, or will send the signal to a PID that is not currently in use, resulting in the error kill: `PID`: No such process.

   ### Why Use `/bin/kill`?:

   Many shells provide `kill` as a built in command, meaning that the shell will send the signal directly, rather than running `/bin/kill`. Be aware that different shells have a different syntax for specifying the name of the signal to send. Rather than try to learn all of them, it can be simpler to use `/bin/kill `...`` directly.

When sending other signals, substitute `TERM` or `KILL` in the command line as necessary.

### Important:

Killing a random process on the system can be a bad idea. In particular, init(8), PID 1, is special. Running `/bin/kill -s KILL 1` is a quick, and unrecommended, way to shutdown the system. Always double check the arguments to kill(1) before pressing Return.

[2] There are a few tasks that can not be interrupted. For example, if the process is trying to read from a file that is on another computer on the network, and the other computer is unavailable, the process is said to be “uninterruptible”. Eventually the process will time out, typically after two minutes. As soon as this time out occurs the process will be killed.

Prev | Up | Next
4.7. Processes | Home | 4.9. Shells

This, and other documents, can be downloaded from http://ftp.FreeBSD.org/pub/FreeBSD/doc/

For questions about FreeBSD, read the documentation before contacting <questions@FreeBSD.org>.
For questions about this documentation, e-mail <doc@FreeBSD.org>.