Wie kann man einen Prozess beenden, der niemals stirbt?


26

Problem

Ich habe Java-Prozess, der weder mit SIGTERM noch SIGKILL stirbt.

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

Es wird jedes Mal neu gestartet, wenn ein Signal empfangen wird.

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

Es klingt seltsam, aber selbst wenn ich den Server neu starte, stirbt er immer noch nicht .

Der Prozess wurde über das Init-Skript mit dem folgenden Befehl ausgeführt:

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} &

Gibt es eine Möglichkeit, diesen Prozess zum Beenden zu zwingen, außer das Betriebssystem neu zu installieren?

Umgebung

Prozess:

logstash 5.0.0~alpha5

Betriebssystem:

Red Hat Enterprise Linux Server release 6.7 (Santiago)

Java-Version:

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)

Der Server wird unter Microsoft Azure bereitgestellt.


Das Umbenennen einer der erforderlichen Dateien für den Prozess vor dem Beenden sollte einen erfolgreichen Neustart verhindern.
Hagen von Eitzen

6
Du musst es enthaupten! Dieser Prozess ist eindeutig ein Highlander.
Beppe9000

4
@ beppe9000 Und während wir in dieser Stimmung sind, könnten wir genauso gut seine Eltern hinrichten.
Dmitry Grigoryev

2
Sobald ich den Titel gesehen hatte, wusste ich, dass das Logstash
Mark Henderson

1
Schieße mit einer Adamantium-Kugel in den Kopf.
noɥʇʎԀʎzɥʇʎԀʎ

Antworten:


77

init: Hauptprozess logstash (2546) wird durch das Signal KILL abgebrochen

Eigentlich hört Ihr Prozess hier auf.

init: Der Hauptprozess von logstash wurde beendet und erneut gestartet

Ein neuer Logstash-Prozess wird von init gestartet, um ihn zu ersetzen.


Dies zeigt auch, welcher Steuerungsprozess für den Neustart von logstash: init verantwortlich ist . (Bei RHEL 6 und CentOS ist dies Upstart.) Ihr Prozess wird höchstwahrscheinlich entweder über /etc/inittabeine Drop-In-Datei /etc/init/logstash.confoder eine ähnliche Datei gestartet und sollte mit dem entsprechenden Tool gesteuert werden, initctlnicht mit kill.

Versuchen initctl listSie festzustellen, ob der Logstash vorhanden ist.

Dann initctl stop logstashwird es aufhören.

Wenn Sie die conf-Datei in / etc / init bearbeiten oder entfernen, können Sie sie dauerhaft deaktivieren.

Möglicherweise können Sie den Job sogar mit den Befehlen serviceund chkconfigsteuern.


4
+1 für die Verwendung des richtigen Werkzeugs für den Job.
Mast

0

Dies liegt wahrscheinlich daran, dass Logstash-Relay ausgeführt wird. Sie sollten versuchen, Logstash-Relay zu stoppen

nach dieser überprüfung, ob das ps da ist, dann initctl liste | Sortieren

Ich hoffe, dies wird dir helfen! Es hat das Problem für mich behoben!

Vielen Dank

VR


Aus den Informationen in der Frage geht eindeutig hervor, dass es sich um initdie Person handelte, die für das erneute Aufstellen des Prozesses verantwortlich war.
Kasperd
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.