docs/handbook/handbook-basics-daemons.mdwn

   1 \r
   2 \r
   3 ## Daemons, Signals, and Killing Processes \r
   4 \r
   5 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.\r
   6 \r
   7 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 mascot for a number of BSD-based operating systems has, for a long time, been a cheerful looking daemon with sneakers and a pitchfork.\r
   8 \r
   9 There is a convention to name programs that normally run as daemons with a trailing ***d***.  **BIND**  is the Berkeley Internet Name Daemon (and 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.\r
  10 \r
  11 Sometimes you will need to communicate with a daemon process. These communications are called ***signals***, and you can communicate with a daemon (or with any other running process) by sending it 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)](http://leaf.dragonflybsd.org/cgi/web-man?command#kill&section1) or [kill(2)](http://leaf.dragonflybsd.org/cgi/web-man?command=kill&section=2) permission will be denied. The exception to this is the `root` user, who can send signals to everyone's processes.\r
  12 \r
  13 DragonFly 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, DragonFly sends the process the ***Segmentation Violation*** signal (`SIGSEGV`). If an application has used the [alarm(3)](http://leaf.dragonflybsd.org/cgi/web-man?command#alarm&section3) system call to be alerted after a period of time has elapsed then it will be sent the Alarm signal (`SIGALRM`), and so on.\r
  14 \r
  15 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.\r
  16 \r
  17 `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 DragonFly will stop that process there and then[(1)](#FTN.AEN2181).\r
  18 \r
  19 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.\r
  20 \r
  21 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.\r
  22 \r
  23 Signals are sent using the [kill(1)](http://leaf.dragonflybsd.org/cgi/web-man?command#kill&section1) command, as this example shows.\r
  24 \r
  25  **Sending a Signal to a Process** \r
  26 \r
  27 This example shows how to send a signal to [inetd(8)](http://leaf.dragonflybsd.org/cgi/web-man?command#inetd&section8). The `inetd` configuration file is `/etc/inetd.conf`, and `inetd` will re-read this configuration file when it is sent `SIGHUP`.\r
  28 \r
  29   1. Find the process ID of the process you want to send the signal to. Do this using [ps(1)](http://leaf.dragonflybsd.org/cgi/web-man?command#ps&section1) and [grep(1)](http://leaf.dragonflybsd.org/cgi/web-man?command=grep&section=1). The [grep(1)](http://leaf.dragonflybsd.org/cgi/web-man?command=grep&section=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)](http://leaf.dragonflybsd.org/cgi/web-man?command=inetd&section=8) is run as `root`, so the `ax` options must be given to [ps(1)](http://leaf.dragonflybsd.org/cgi/web-man?command=ps&section=1).\r
  30       \r
  31       % ps -ax | grep inetd\r
  32         198  ??  IWs    0:00.00 inetd -wW\r
  33   \r
  34   So the [inetd(8)](http://leaf.dragonflybsd.org/cgi/web-man?command#inetd&section8) PID is 198. In some cases the `grep inetd` command might also occur in this output. This is because of the way [ps(1)](http://leaf.dragonflybsd.org/cgi/web-man?command=ps&section=1) has to find the list of running processes.\r
  35   1. Use [kill(1)](http://leaf.dragonflybsd.org/cgi/web-man?command#kill&section1) to send the signal. Because [inetd(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=inetd&section=8) is being run by `root` you must use [su(1)](http://leaf.dragonflybsd.org/cgi/web-man?command=su&section=1) to become `root` first.\r
  36       \r
  37       % su\r
  38       Password:\r
  39       # /bin/kill -s HUP 198\r
  40   \r
  41   In common with most UNIX® commands, [kill(1)](http://leaf.dragonflybsd.org/cgi/web-man?command#kill&section1) 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`.\r
  42 \r
  43    **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.\r
  44 \r
  45 Sending other signals is very similar, just substitute `TERM` or `KILL` in the command line as necessary.\r
  46 \r
  47  **Important:** Killing random process on the system can be a bad idea. In particular, [init(8)](http://leaf.dragonflybsd.org/cgi/web-man?command#init&section8), 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)](http://leaf.dragonflybsd.org/cgi/web-man?command=kill&section=1) with ***before*** you press  **Return** .\r
  48 \r
  49 #### Notes \r
  50 \r
  51 [[!table  data="""
  52 |<tablestyle="width:100%"> [(1)](basics-daemons.html#AEN2181) | Not quite true--there are a few things 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 has gone away for some reason (been turned off, or the network has a fault), then 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. |\r
  53 """]]\r
  54 \r
  55 \r
  56 CategoryHandbook\r
  57 CategoryHandbook-basics\r