Sujet: Question bête sur la commande killall

[Minusk]

Bonjour,

Je vois souvent que pour couper un process sous dm la commande est killall -9 Nomprocess.

J'ai regarder sur la doc Busybox, mais je vois pas a quoi correspond le -9

killall

    killall [-l] [-q] [-SIG] process-name...

    Send a signal (default: TERM) to given processes

    Options:

            -l      List all signal names and numbers
            -q      Do not complain if no processes were killed

Voila si quelqu'un pouvait me renseigner à quoi correspond se -9.

Par avance merci.

Ps: ça fonctionne parfaitement comme commande, juste que je ne vois pas ce qu'apporte le -9

[superroockie]

Arf, tu risque de pas aimer ma réponse

Au lieu d'envoyer SIGTERM, ca envoi -9 (donc SIGKILL) au process.

Ca permet d'informer le process de ce qui lui arrive au cas ou quelque chose a été prévu par le process, c'est une bonne habitude à prendre

sr

[Parodin]

Amusant, ma vision est assez différente:

SIGTERM demande poliment à un processus de se terminer en faisant toutes les opérations prévues dans ce cas-là
SIGKILL (-9) au contraire provoque l'arrêt brutal d'un processus sans passer par le start, ne touche donc pas les 4000 francs

Pour moi le -9 n'est à utiliser que quand un kill normal ne suffit pas

Un troisième avis ??

[superroockie]

Oui, on peut le voir comme ca, moi je met -9 parce que si je fait un kill , je veut vraiment le killer, pas lui demander gentillement de s'arrêter s'il le veut :p

sr

[Minusk]

Merci a vous, donc le -9 permet de forcer la fin d'un process que celui ci le veuille ou pas.

[x-or]

Amusant, ma vision est assez différente:

SIGTERM demande poliment à un processus de se terminer en faisant toutes les opérations prévues dans ce cas-là
SIGKILL (-9) au contraire provoque l'arrêt brutal d'un processus sans passer par le start, ne touche donc pas les 4000 francs

Pour moi le -9 n'est à utiliser que quand un kill normal ne suffit pas

Un troisième avis ??

+1 !

Moi j'aime bien le -9 ... ca doit être mon coté psychopathe

X.

[Dirac]

Bonjour

Voici un 3ème avis.

La question initialement posée peut conduire à une réponse de plusieurs pages...
Elle touche un sujet important qui mériterait de sortir ce fil du chapitre dreambox 8000, puisqu'il concerne toute machine à base d'unix et même toute machine dont le noyau est interfacé POSIX.
Je tente d'être bref et imagé. Dans un contexte multitâche, les processus interagissent au sein d'une même famille de processus. L'une des méthodes de communication, simple et peu couteuse, est l'utilisation des signaux qui sont des évènements que je vais assimiler à des fléchettes. Il existe plusieurs couleurs de fléchettes.
Deux règles simples pour comprendre l'interaction:
 - quand on dit (abusivement) qu'un processus P1 envoie un signal à un processus P2, celà signifie que P1 demande au noyau d'émettre le signal en direction du processus P2; pour celà P1 utilise une primitive du noyau.
 - on choisit la couleur de la fléchette (la valeur du signal notée SIGxxxx) en fonction de l'effet désiré. Le nombre de valeurs différentes est variable suivant les NOYAUX (30 sur la PoD de mai 2010).
Exemples d'évènements à l'origine de l'émission de signaux vers un processus: changement de la taille de la fenêtre de l'application, exécution d'une instruction illégale, tentative de visite d'une mémoire non autorisée, temporisation terminée, synchronisation avec un autre processus ayant terminé un certain travail, décès d'un processus enfant, tentative d'avortement du processus courant par l'opérateur (CTRL/C par exemple), endormissement du processus, réveil, ...

Comme son nom ne l'indique pas, la commande kill va permettre à un opérateur (ou à un script) de simuler l'un des évènements cités pour le processus visé par la fléchette; cette commande permet donc FACILEMENT de tester le comportement du processus lorsqu'il survient un tel évènement.

Que se passe-t-il coté processus?
1) si le processus est lié à une application manipulant des données importantes(enregistrement, sauvegardes,..) ou du matériel extérieur lié à la machine, l'application doit les préserver en gérant les fléchettes dangereuses pour sa survie; celà se fait en écrivant une fonction bouclier (appelée handler du (ou des) signal). Chaque fléchette de couleur donnée sera traitée par sa fonction bouclier.
C'est ici qu'intervient la couleur 9 (SIGKILL). Cette fléchette est imparable et tout processus la recevant sera irrémédiablement tué et ôté de la table des processus en cours. En outre, ses données ne seront pas sauvegardées, ses processus enfants vont devenir orphelins et devront être recueillis par l'ancêtre (PID:1), ...

Je suis de l'avis de Parodin sur ce sujet, si on souhaite terminer un processus, il vaut mieux le faire proprement en demandant au processus de se terminer lui-même (suicide), il veillera ainsi au salut préalable de ses données et à l'extermination de sa progéniture.
2) si l'application ne contient pas de fonction bouclier, suivant la couleur de la fléchette, le processus va
 soit se terminer brutalement
 soit ignorer la fléchette
 soit s'endormir (debug pas à pas)
 soit se réveiller
Pour certains signaux, le moyau va créer un fichier core qui est l'image de l'application au moment de sa mort; sa lecture permet de connaître la cause de son décès ( la couleur de la flèche mortelle).

Si ma réponse est trop longue, j'accepte volontiers qu'elle soit gommée...
Dirac

[Doume]

Il n'y a pas de réponses trop longues, lorsqu'elles sont de cette qualité
Merci, Dirac

[AmadeusHF]

On peut préciser un poil quand même...

SIGTERM est effectivement utilisé pour une "gracefully termination", là ou SIGKILL induit un arret définitif du process.

Pourquoi un -9 c'est mmaaaaaalll ?

Parce que l'effet d'un -9 dépasse la simple possiblité de corruption de données.
Un -9 ne permet pas à l'application de libérer l'ensemble des ressources qu'elle utilise.

Si en ce qui concerne le noyau, ce dernier va généralement faire lui-même le ménage, tout n'est pas si simple et, suivant les cas, il arrive qu'un process supprimé par -9 laisse une trace en mémoire (dans des ressources hardware) ou ne dévérouille pas un équipement qui, par la suite, devient indisponible.

Bien entendu, ça dépend pour beaucoup de la manière dont sont pilotées lesdites ressources, mais ca reste un problème.

Donc on peut la jouer bourrin et toujours faire un -9 brutal, ou préférer passer par un SIGTERM d'abord puis tenter un SIGKILL ensuite, si le SIGTERM n'a pas donné le résultat.

Enfin, ajoutons que ça dépend AUSSI de l'OS et de ses composants. Par exemple : sur un TGS, killall sur hypercam va l'arréter systématiquement, sauf si la machine est sévèrement plantée. La même chose sur une DM 7020 a tendance à ne PAS arréter le process alors que celui-ci fonctionne parfaitement et gère très proprement SIGTERM.

Une pratique saine peut consister à regarder l'impact d'un kill -9 sur les ressources (empiriquement) afin de voir si tout est bien libéré par l'OS et, dans ce cas, on peut utiliser le -9 au quotidien.

Pour la petite histoire, faire un kill -9 sur Enigma sur certains décos (TGS à une époque notamment) peut signifier reboot obligatoire : les devices tels que le framebuffer ne sont pas correctement fermés et enigma ne sait plus les réouvrir. Ici, ce sont les drivers qui sont en cause...

[Minusk]

Par exemple : sur un TGS, killall sur hypercam va l'arréter systématiquement, sauf si la machine est sévèrement plantée. La même chose sur une DM 7020 a tendance à ne PAS arréter le process alors que celui-ci fonctionne parfaitement et gère très proprement SIGTERM.

D'abord merci pour les réponses, part contre si je suis bien ton explication, si je veux mettre un terme a un process de façon automatique sur n'importe quel demo linux. Il faudrait dans l'absolue que je fasse un test avec une commande SIGTERM  en premier, puis vérifier avec un ps si le process est hs, si toujours actif seulement utiliser a se moment la un killall -9 (donc SIGKILL)  ?

[AmadeusHF]

tout à fait.