===== Daemons, Signals and Killing Processes =====

===Daemons=== 


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//.
<code bash>

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

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.
<code bash>

debian:/$ su
Password:
debian:/# kill -s HUP 3122
</code>


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.