Jak zabić proces, który nigdy nie umiera?

Problem

Mam proces Java, który nie umiera ani z SIGTERM, ani z 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

Odradza się za każdym razem, gdy odbierany jest sygnał.

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

Brzmi dziwnie, ale nawet po ponownym uruchomieniu serwera nadal nie umiera .

Proces został wykonany za pomocą skryptu inicjującego z poniższym poleceniem:

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

Czy jest jakiś sposób, aby zmusić ten proces do zabicia poza ponownym zainstalowaniem systemu operacyjnego?

Środowisko

Proces :

logstash 5.0.0~alpha5

OS:

Red Hat Enterprise Linux Server release 6.7 (Santiago)

Wersja 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)

Serwer jest wdrażany na Microsoft Azure.

linux centos6 logstash

— Yu Watanabe
źródło

Zmiana nazwy jednego z wymaganych plików dla procesu przed zabiciem powinna uniemożliwić jego ponowne uruchomienie.

— Hagen von Eitzen,

Musisz to ściąć! Ten proces najwyraźniej jest Góralem.

— beppe9000,

@ beppe9000 I kiedy jesteśmy w takim nastroju, równie dobrze możemy zabić jego rodziców.

— Dmitry Grigoryev

Gdy tylko zobaczyłem tytuł, wiedziałem, że będzie to Logstash

— Mark Henderson

Zastrzel go kulą adamantium w głowę.

— noɥʇʎԀʎzɐɹƆ

Odpowiedzi:

init: główny proces logstash (2546) zabity sygnałem KILL

W rzeczywistości proces tutaj się kończy.

init: główny proces logstash zakończony, odrodzenie

Nowy proces logstash jest uruchamiany przez init go zastąpić.

To także pokazuje, który proces kontroli jest odpowiedzialny za ponowne uruchomienie logstash: init . (Na RHEL 6 i CentOS, który jest w fazie Upstart) Najprawdopodobniej proces rozpoczyna się od jednego z /etc/inittabplików rozwijanych /etc/init/logstash.conf(lub podobnych) i powinien być kontrolowany za pomocą odpowiedniego narzędzia, initctla nie za pomocą kill.

Spróbuj initctl listsprawdzić, czy jest tam logstash.

Wtedy initctl stop logstashto zatrzyma.

Edycja lub usunięcie pliku conf w / etc / init pozwoli ci trwale go wyłączyć.

Możesz nawet być w stanie kontrolować zadanie za pomocą poleceń servicei chkconfig.

— HBruijn
źródło

+1 za użycie odpowiedniego narzędzia do pracy.

— Maszt

Jest to prawdopodobnie spowodowane uruchomieniem przekaźnika logstash ... Powinieneś spróbować zatrzymać przekaźnik logstash

po tym sprawdzeniu, czy ps tam jest, następnie lista initctl | sortować

Mam nadzieję, że to Ci pomoże! Naprawiłem problem!

Dzięki

— vrousseu
źródło

Informacje w pytaniu wyraźnie wskazują, że to on initbył odpowiedzialny za odrodzenie procesu.

— kasperd