3.8. Daemons, signaux, et comment tuer un processus

Quand vous utilisez un éditeur il est facile de le contrôler, de lui dire de charger des fichiers, et ainsi de suite. Vous pouvez faire cela parce que l'éditeur fournit les possibilités de le faire, et parce qu'un éditeur est attaché à un terminal. Certains programmes ne sont pas conçus pour fonctionner avec un dialogue constant avec l'utilisateur, et donc ils se déconnectent du terminal à la première occasion. Par exemple, un serveur web passe son temps à répondre aux requêtes web, il n'attend normalement pas d'entrée de votre part. Les programmes qui transportent le courrier électronique de site en site sont un autre exemple de cette classe d'application.

Nous appelons ces programmes des daemons (démons). Les ``daemons'' étaient des personnages de la mythologie Grec; ni bon ni mauvais, c'étaient de petits esprits serviteurs qui, généralement, ont été à l'origine de choses utiles à l'humanité. Un peu comme les serveurs web ou de courrier d'aujourd'hui nous sont utiles. C'est pourquoi la mascotte BSD a été, pendant longtemps, un démon à l'apparence joyeuse portant des chaussures de tennis et une fourche.

Il existe une convention pour nommer les programmes qui fonctionnent normalement en tant que daemons qui est d'utiliser une terminaison en ``d''. BIND est le ``Berkeley Internet Name Daemon'' (et le programme réel qui est exécuté s'appelle named), le programme correspondant au serveur web Apache est appelé httpd, le daemon de gestion de la file d'attente de l'imprimante est lpd, et ainsi de suite. C'est une convention, mais pas une obligation pure et simple; par exemple le daemon principal de gestion du courrier électronique pour l'application Sendmail est appelé sendmail, et non pas maild, comme vous pourriez l'imaginer.

Parfois vous devrez communiquer avec un processus daemon. Ces communications sont appelées signaux, et vous pouvez communiquez avec un daemon (ou avec tout processus en fonctionnement) en lui envoyant un signal. Il existe un certain nombre de signaux différents que vous pouvez envoyer--certains d'entre eux ont une signification précise, d'autres sont interprétés par l'application, et la documentation de l'application vous indiquera comment l'application interprète ces signaux. Vous ne pouvez envoyer de signaux qu'aux processus dont vous êtes le propriétaire. Si vous envoyez un signal à un processus appartenant à quelqu'un d'autre avec kill(1) ou kill(2) vous obtiendrez un refus de permission. Il existe une exception à cela: l'utilisateur root, qui peut envoyer des signaux aux processus de chacun.

Dans certain cas FreeBSD enverra également aux applications des signaux. Si une application est mal écrite, et tente d'accéder à une partie de mémoire à laquelle elle n'est pas supposée avoir accès, FreeBSD envoie au processus le signal de violation de segmentation (SIGSEGV). Si une application a utilisé l'appel système alarm(3) pour être avertie dès qu'une période de temps précise est écoulée alors lui sera envoyé le signal d'alarme (SIGALRM), et ainsi de suite.

Deux signaux peuvent être utilisés pour arrêter un processus, SIGTERM et SIGKILL. SIGTERM est la manière polie de tuer un processus; le processus peut attraper le signal, réaliser que vous désirez qu'il se termine, fermer les fichiers de trace qu'il a peut-être ouvert, et généralement finir ce qu'il était en train de faire juste avant la demande d'arrêt. Dans certains cas un processus peut ignorer un SIGTERM s'il est au milieu d'une tâche qui ne peut être interrompue.

SIGKILL ne peut être ignoré par un processus. C'est le signal ``Je me fiche de ce que vous faites, arrêtez immédiatement''. Si vous envoyez un SIGKILL à un processus alors FreeBSD stoppera le processus[1].

Les autres signaux que vous pourriez avoir envie d'utiliser sont SIGHUP, SIGUSR1, et SIGUSR2. Ce sont des signaux d'usage général, et différentes applications se comporteront différemment quand ils sont envoyés.

Supposez que vous avez modifié le fichier de configuration de votre serveur web--vous voudriez dire à votre serveur web de relire son fichier de configuration. Vous pourriez arrêter et relancer httpd, mais il en résulterait une brève période d'indisponibilité de votre serveur web, ce qui peut être indésirable. La plupart des daemons sont écrits pour répondre au signal SIGHUP en relisant leur fichier de configuration. Donc au lieu de tuer et relancer httpd vous lui enverriez le signal SIGHUP. Parce qu'il n'y a pas de manière standard de répondre à ces signaux, différents daemons auront différents comportements, soyez sûr de ce que vous faites et lisez la documentation du daemon en question.

Les signaux sont envoyés en utilisant la commande kill(1), comme cet exemple le montre:

Envoyer d'autres signaux est très semblable, substituez juste TERM ou KILL dans la ligne de commande si nécessaire.