When you run an editor it is easy to control the editor, tell it to load files, and so
on. You can do this 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 so they disconnect from the terminal at the
first opportunity. For example, a web server spends all day responding to web requests,
it normally does not need any input from you. Programs that transport email from site to
site are another example of this class of application.
We call these programs daemons. Daemons were characters in
Greek mythology: neither good or evil, they were little attendant spirits that, by and
large, did useful things for mankind, much like the web servers and mail servers of today
do useful things. This is why the BSD mascot has, for a long time, been 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 called named; the Apache web server program is called httpd; the line printer spooling daemon is lpd and so on. This is a convention, not a hard and fast rule; for
example, the main mail daemon for the Sendmail application is
called sendmail, and not maild, as you
might imagine.
Sometimes you will need to communicate with a daemon process. One way to do so is to
send it (or any other running process), what is known as a signal. There are a number of different signals that you can
send--some of them have a specific meaning, others are interpreted by the application,
and the application's documentation will tell you how that application interprets
signals. You can only send a signal to a process that you own. If you send a signal to
someone else's process with kill(1) or kill(2), permission
will be denied. The exception to this is the root user, who can
send signals to everyone's processes.
FreeBSD will also send applications signals in some cases. If an application is badly
written, and tries to access memory that it is not supposed to, FreeBSD sends 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 then it will be sent the Alarm signal
(SIGALRM), and so on.
Two signals can be used to stop a process, SIGTERM and SIGKILL. SIGTERM is the polite way to kill
a process; the process can catch
the signal, realize that you want it to shut down, close any log files it may have open,
and generally finish whatever it is doing at the time before shutting down. In some cases
a process may even 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. If you send SIGKILL to a process then FreeBSD will stop that process there and
then.
The other signals you might want to use are SIGHUP, SIGUSR1, and SIGUSR2. These are general
purpose signals, and different applications will do different things when they are
sent.
Suppose that you have changed your web server's configuration file--you would like to
tell the web server to re-read its configuration. You could stop and restart httpd, but this would result in a brief outage period on your web
server, which may be undesirable. Most daemons are written to respond to the SIGHUP signal by re-reading their configuration file. So instead of
killing and restarting httpd you would send it the SIGHUP signal. Because there is no standard way to respond to these
signals, different daemons will have different behavior, so be sure and read the
documentation for the daemon in question.
Signals are sent using the kill(1) command, as
this example shows.
Sending a Signal to a Process
This example shows how to send a signal to inetd(8). The inetd configuration file is /etc/inetd.conf, and inetd will re-read
this configuration file when it is sent SIGHUP.
-
Find the process ID of the process you want to send the signal to. Do this using ps(1) and grep(1). The grep(1) command is
used to search through output, looking for the string you specify. This command is run as
a normal user, and inetd(8) is run as root, so the ax options must be given
to ps(1).
% ps -ax | grep inetd
198 ?? IWs 0:00.00 inetd -wW
So the inetd(8) PID is 198.
In some cases the grep inetd command might also appear in this
output. This is because of the way ps(1) has to find the
list of running processes.
-
Use kill(1) to send the
signal. Because inetd(8) is being run
by root you must use su(1) to become root first.
% su
Password:
# /bin/kill -s HUP 198
In common with most UNIX® commands, kill(1) will not print
any output if it is successful. If you send a signal to a process that you do not own
then you will see “kill: PID: Operation not permitted”. If you mistype
the PID you will either send the signal to the wrong process, which could be bad, or, if
you are lucky, you will have sent the signal to a PID that is not currently in use, and
you will see “kill: PID:
No such process”.
Why Use /bin/kill?: Many shells provide the kill command as a built in command; that is, the shell will send the
signal directly, rather than running /bin/kill. This can be
very useful, but 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 just to use the
/bin/kill ... command
directly.
Sending other signals is very similar, just substitute TERM
or KILL in the command line as necessary.
Important: Killing random process on the system can be a bad idea. In
particular, init(8), process ID 1,
is very special. Running /bin/kill -s KILL 1 is a quick way to
shutdown your system. Always double
check the arguments you run kill(1) with before you press Return.
