killall me donne "aucun processus trouvé" mais ps

Est-ce sous Linux ?

Il existe en fait quelques versions subtilement différentes du nom de la commande qui sont utilisées par ps , killall , etc.

Les deux variantes principales sont :1) le nom de commande long, qui correspond à ce que vous obtenez lorsque vous exécutez ps u; et 2) le nom court de la commande, qui correspond à ce que vous obtenez lorsque vous exécutez ps sans aucun drapeau.

La plus grande différence se produit probablement si votre programme est un script shell ou tout ce qui nécessite un interpréteur, par ex. Python, Java, etc.

Voici un script vraiment trivial qui démontre la différence. Je l'ai appelé mycat :

#!/bin/sh
cat

Après l'avoir exécuté, voici les deux types différents de ps .

Premièrement, sans u :

$ ps -p 5290
  PID TTY      ... CMD
 5290 pts/6    ... mycat

Deuxièmement, avec u :

$ ps u 5290
USER       PID ... COMMAND
mikel     5290 ... /bin/sh /home/mikel/bin/mycat

Notez comment la deuxième version commence par /bin/sh ?

Maintenant, pour autant que je sache, killall lit réellement /proc/<pid>/stat , et saisit le deuxième mot entre les parenthèses comme nom de commande, donc c'est vraiment ce que vous devez spécifier lorsque vous exécutez killall . Logiquement, cela devrait être le même que ce que ps sans le u flag dit, mais ce serait une bonne idée de vérifier.

Choses à vérifier :

1. que signifie cat /proc/<pid>/stat dites que le nom de la commande est ?
2. que signifie ps -e | grep db2 dites que le nom de la commande est ?
3. faire ps -e | grep db2 et ps au | grep db2 afficher le même nom de commande ?

Remarques

Si vous utilisez également d'autres drapeaux ps, vous trouverez peut-être plus simple d'utiliser ps -o comm pour voir le nom court et ps -o cmd pour voir le nom long.

Vous pouvez également trouver pkill une meilleure alternative. En particulier, pkill -f essaie de faire correspondre le nom complet de la commande, c'est-à-dire le nom de la commande tel qu'il est imprimé par ps u ou ps -o cmd .

killall essaie de faire correspondre un nom de processus (mais n'est pas vraiment bon pour la partie correspondante).

Et puisque "ps | grep" et "ps | grep | kill" font un bien meilleur travail, quelqu'un a simplifié cela et a créé pgrep et pkill. Lisez ces commandes comme "ps grep" et "ps kill", puisque cette commande d'abord ps puis grep et si vous le souhaitez tue.

J'ai eu un problème similaire mais /proc/<pid>/stat contenait la chaîne attendue. En utilisant strace, j'ai pu voir que killall avait également accédé à /proc/<pid>/cmdline .

J'ai continué à enquêter sur l'utilisation de gdb pour constater que dans mon cas, il a échoué lors d'une vérification de ma commande à la commande complète, y compris tous les arguments trouvés dans /proc/<pid>/cmdline . Il semblait que ce chemin du code s'était déclenché car le nom de fichier était plus long que 15 caractères (qui est une valeur codée en dur dans la source de killall). Je n'ai pas vraiment cherché à savoir si je pouvais d'une manière ou d'une autre le faire fonctionner avec killall.

Mais comme mentionné dans d'autres commentaires ici, pkill est une meilleure alternative qui n'a pas les mêmes problèmes.

Le code source de pkill peut être trouvé ici https://github.com/acg/psmisc pour les intéressés.