Comment tuer un processus qui ne meurt jamais?

Problème

J'ai un processus java qui ne meurt ni avec SIGTERM ni SIGKILL.

logstash  2591     1 99 13:22 ?        00:01:46 /usr/bin/java -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly -XX:+DisableExplicitGC -Djava.awt.headless=true -Dfile.encoding=UTF-8 -XX:+HeapDumpOnOutOfMemoryError -Xmx1g -Xms256m -Xss2048k -Djffi.boot.library.path=/usr/share/logstash/vendor/jruby/lib/jni -Xbootclasspath/a:/usr/share/logstash/vendor/jruby/lib/jruby.jar -classpath : -Djruby.home=/usr/share/logstash/vendor/jruby -Djruby.lib=/usr/share/logstash/vendor/jruby/lib -Djruby.script=jruby -Djruby.shell=/bin/sh org.jruby.Main --1.9 /usr/share/logstash/lib/bootstrap/environment.rb logstash/runner.rb --path.settings /etc/logstash

Il réapparaît chaque fois qu'un signal est reçu.

Sep 15 13:22:17 test init: logstash main process (2546) killed by KILL signal
Sep 15 13:22:17 test init: logstash main process ended, respawning

Cela semble étrange mais même si je redémarre le serveur, il ne meurt toujours pas .

Le processus a été exécuté via le script init avec la commande ci-dessous:

NAME=logstash
LS_USER=logstash
LS_OPTS="--path.settings=/etc/logstash"
LS_PIDFILE=/var/run/$NAME/$NAME.pid
LS_STDERR="/var/log/logstash/logstash.stderr"
DAEMON="/usr/share/logstash/bin/logstash"

runuser -s /bin/sh -c "exec $DAEMON ${LS_OPTS}" ${LS_USER} &>${LS_STDERR} &

Existe-t-il un moyen de forcer ce processus à tuer autre que la réinstallation du système d'exploitation?

Environnement

Processus:

logstash 5.0.0~alpha5

OS:

Red Hat Enterprise Linux Server release 6.7 (Santiago)

Version Java:

openjdk version "1.8.0_101"
OpenJDK Runtime Environment (build 1.8.0_101-b13)
OpenJDK 64-Bit Server VM (build 25.101-b13, mixed mode)

Le serveur est déployé sur Microsoft Azure.

linux centos6 logstash

— Yu Watanabe
source

Renommer l'un des fichiers requis pour le processus électronique avant de le tuer devrait l'empêcher de redémarrer avec succès.

— Hagen von Eitzen

Tu dois le décapiter! Ce processus est clairement un Highlander.

— beppe9000

@ beppe9000 Et pendant que nous sommes dans cette humeur, nous pourrions aussi bien exécuter ses parents.

— Dmitry Grigoryev

Dès que j'ai vu le titre, je savais que ce serait Logstash

— Mark Henderson

Tirez dessus avec une balle en adamantium dans la tête.

— noɥʇʎԀʎzɐɹƆ

Réponses:

init: processus principal logstash (2546) tué par le signal KILL

En fait, votre processus s'arrête là.

init: processus principal de logstash terminé, réapparition

Un nouveau processus logstash est démarré par init pour le remplacer.

Cela montre également quel processus de contrôle est responsable du redémarrage de logstash: init . (Sur RHEL 6 et CentOS qui est Upstart) Votre processus démarre très probablement à partir de l'un /etc/inittabou d'un fichier de dépôt dans /etc/init/logstash.conf(ou similaire) et doit être contrôlé avec l'outil approprié, initctlet non avec kill.

Essayez initctl listde voir s'il y a une logstash.

Alors initctl stop logstashl'arrêtera.

La modification ou la suppression du fichier conf dans / etc / init vous permettra de le désactiver de manière permanente.

Vous pourriez même être en mesure de contrôler le travail avec les commandes serviceet chkconfig.

— HBruijn
source

+1 pour l'utilisation du bon outil pour le travail.

— mât

C'est probablement parce que logstash-relay est en cours d'exécution ... Vous devriez essayer d' arrêter logstash-relay

après cette vérification si le ps est là alors liste initctl | Trier

J'espère que cela t'aidera! Cela a résolu le problème pour moi!

Merci

— vrousseu
source

Les informations contenues dans la question indiquent clairement que c'est lui initqui était responsable de la réapparition du processus.

— kasperd