User Tools

Site Tools


Daemons, Signals and Killing Processes


Special small programs that perform specific tasks. A daemon may run all the time “watching” a system or they may “wake up” when a task needs to be performed. For example the program that wakes up to deliver a mail message, or a file to be printed. When a mail message cannot be delivered you may receive a message from the mailer daemon. The daemon program name usually ends in `d', eg: lpd, inetd, httpd, ftpd, sshd, etc.

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) or kill(2) permission will be denied. The exception to this is the root user, who can send signals to everyone's processes.

Sometimes, the Linux kernel will send application signals. If this application tries to access memory that it is not supposed to access, Linux sends to the process the Segment Violation (SIGSEGV) signal. If an application uses the alarm system call this will send the SIGALRM signal, and so on.

There are a couple of signals that can be sent to interrupt a process : SIGTERM and SIGKILL.

  • SIGTERM is the nice way to kill a process. The process catches the signal, understands that you want it to 'die', closes any files that it may have open, and generally finishes whatever it was doing before it recieved the SIGTERM . However, sometimes a process could ignore SIGTERM it it's in the middle of a task that can not be stopped.
  • SIGKILL can not be ignored by a process. This is the “STOP NOW” signal. If you send SIGKILL to a process then Linux will stop that process instantaneously.

Other signals you can use are SIGHUP, SIGUSR1, and SIGUSR2. These are general purpose signals, and different applications will do different things when they are sent.

Most daemons are made to respond to the SIGHUP signal by re-reading their configuration file. So instead of killing and restarting a daemon you would send it the SIGHUP signal. (NOTE: However, different daemons will have different behavior, so be sure and read the documentation for the daemon in question.)

Sending a Signal to a Process

This example shows how to send a signal to the inetd daemon. The inetd configuration file is /etc/inetd.conf, and inetd will re-read this configuration file when it encounters SIGHUP.

1. First, you need to find the PID (process id) of the process you want to send the signal to. You can do this using the ps and grep commands. The grep(1) command is used to search through the output, looking for the string you supply. This command is run as a normal user, and inetd(8) is run as root, so we need the ax option for ps.

debian:/$ ps -ax | grep inetd
3122 ? Ss 0:00 /usr/sbin/inetd

Our PID is 3122. In some cases the grep inetd command might also occur in this output. This is because of the way ps(1) finds the list or processes.

2. Kill sends the signal. Because inetd(8) is being run by root you must use su(1) to become root first.

debian:/$ su
debian:/# kill -s HUP 3122

The kill command will not print any output when successful. If you try to kill a signal that you don't own, you will probably see something like : -bash: kill: (PID): Operation not permitted. Careful not to mistype the PID. You could send the kill signal to an important process, or if you are lucky you could send the signal to an inexistent PID. In this case, you will notice something like : -bash: kill: PID: no such pid.

Important: Sending the kill signal to random processes can be a very bad idea. For example, the init, process ID 1 a special one. If you run kill -s KILL 1 it will shutdown your system. While root, always double check the arguments to be sure they are correct.

handbook/handbook/daemons.txt · Last modified: 2010/04/15 21:18 (external edit)