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 Grecque: 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 messagerie 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
Domain”, mais 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.
Une manière de procéder est de lui (ou à tout processus en cours
d'exécution) envoyer ce que l'on appelle 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[4].
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:
Cet exemple montre comment envoyer un signal à
inetd(8). Le fichier de configuration d'inetd
est
/etc/inetd.conf
, et inetd
relira ce
fichier de configuration quand un signal
SIGHUP
est envoyé.
Trouvez l'identifiant du processus (PID) auquel vous
voulez envoyer le signal. Faites-le en employant ps(1)
et grep(1). La commande grep(1) est utilisée pour
rechercher dans le résultat la chaîne de
caractères que
vous spécifiez. Cette commande est lancée en tant
qu'utilisateur normal, et inetd(8) est lancé en tant que
root
, donc les options ax
doivent être passées à ps(1).
%
ps -ax | grep inetd
198 ?? IWs 0:00.00 inetd -wW
Donc le PID d'inetd(8) est 198. Dans certains cas la
commande grep inetd
pourrait aussi
apparaître dans le résultat. C'est à
cause de la façon dont
ps(1) recherche la liste des processus en
fonctionnement.
Utilisez kill(1) pour envoyer le signal. Etant donné
qu'inetd(8) tourne sous les droits de l'utilisateur
root
vous devez utilisez su(1) pour
devenir, en premier lieu, root
.
%
su
Password:
#
/bin/kill -s HUP 198
Comme la plupart des commandes UNIX®, kill(1) n'affichera
rien si la commande est couronnée de succès. Si vous
envoyez un signal à un processus dont vous n'êtes pas le
propriétaire alors vous verrez kill:
PID
: Operation not
permitted. Si vous avez fait une erreur dans le
PID, vous enverrez le signal soit à un mauvais processus, ce
qui peut être mauvais, soit, si vous êtes chanceux, vous
enverrez le signal à un PID qui n'est pas actuellement
utilisé, et vous verrez kill:
PID
: No such
process.
/bin/kill
?: De nombreux interpréteurs de commandes fournissent la
commande kill
comme commande interne;
c'est à dire, que l'interpréteur de commandes enverra
directement le signal, plutôt que de lancer
/bin/kill
. Cela peut être utile,
cependant les différents interpréteurs ont une syntaxe
différente pour spécifier le nom du signal à
envoyer.
Plutôt que de tenter de les apprendre toutes, il peut
être plus simple de juste employer directement la commande
/bin/kill
...
.
Envoyer d'autres signaux est très semblable, substituez juste
TERM
ou KILL
dans la ligne
de commande si nécessaire.
Tuer au hasard des processus sur le système peut
être une mauvaise idée.
En particulier, init(8), processus à
l'identifiant 1, qui est très particulier. Lancer la commande
/bin/kill -s KILL 1
est une manière
rapide d'arrêter votre système. Vérifiez
toujours à deux fois les arguments que vous
utilisez avec kill(1) avant d'appuyer
sur Entrée.
[4] Ce n'est pas tout à fait vrai—il y a quelques cas où les choses ne peuvent être interrompues. Par exemple, si le processus est en train d'essayer de lire un fichier qui est sur un autre ordinateur sur le réseau, et que l'autre ordinateur n'est plus accessible pour quelque raison (a été éteint, ou le réseau a un problème), alors le processus est dit “non interruptible”. Par la suite le processus entrera en pause, typiquement après deux minutes. Dès que cette pause sera effective le processus sera tué.
Ce document, ainsi que d'autres peut être téléchargé sur ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/
Pour toutes questions à propos de FreeBSD, lisez la
documentation avant de contacter
<questions@FreeBSD.org>.
Pour les questions sur cette documentation, contactez
<doc@FreeBSD.org>.