staging.inyokaproject.org

Hallo,

ich betreibe für meinen privaten Eigenbedarf zwei kleine Server bei netcup.

Auf dem PROD-Server habe ich Ubuntu 20.04 installiert. Alles aktuell mit apt update/upgrade.

Ich habe den Server über Publickey authentifiziert, so dass ich via ssh ohne Login Prozedur vom Client auf dem Server komme.

In den letzten Tage habe ich aber ein Performance Thema mit dem Download vom Server und in dem Zusammenhang habe ich die Publickey-Authentifizierung deaktiviert und mich wieder über Password eingeloggt.

Dann habe ich bei den Login folgende Meldung gesehen:

1

There is 1 zombie process

Nach Internet Recherche habe ich folgenden Befehl für die weitere Identifizierung gefunden:

1
2
3
4

ps axo stat,ppid,pid,comm | grep -w defunct

Ausgabe:
Z 1431 3292 rsyslogd <defunct>

Zwei Fragen hierzu:

1. Wie behebe ich diese Meldung mit dem rsyslogd, oder ist dies vernachlässigbar?

2. Kann ich die Meldungen, die nach dem Login über Password auch nachträglich beim Login über Publickey-Authentifizierung manuell ausgeben lassen?

Danke für eine Unterstützung.

kkarsten62

kkarsten62 schrieb:

Nach Internet Recherche habe ich folgenden Befehl für die weitere Identifizierung gefunden:

1 2 3 4

ps axo stat,ppid,pid,comm | grep -w defunct Ausgabe: Z 1431 [mark]3292[/mark] rsyslogd <defunct>

1. Wie behebe ich diese Meldung mit dem rsyslogd, oder ist dies vernachlässigbar?

Du könntest (mit der PPID) schauen, was der Elternprozess von diesem Zombie ist:

ps -fp 3292

und wenn dieser Prozess nicht mehr benötigt wird, ihn (d. h. der Elternprozess) mit "-15" killen:

(sudo) kill -15 3292

Aber i. d. R. ist das nicht erforderlich. Evtl. will er so, warum auch immer, nur seinen "Zustand" mitteilen. Anders wäre es wenn der Zombie-Prozess etwas blockt bzw. offen hält (z. B. einen Port, ...) und nicht frei gibt. Vielleicht kannst Du mit lsof (oder gleichwertig) danach schauen.

lubux schrieb:

...

(sudo) kill -15 3292

Aber i. d. R. ist das nicht erforderlich. Evtl. will er so, warum auch immer, nur seinen "Zustand" mitteilen. Anders wäre es wenn der Zombie-Prozess etwas blockt bzw. offen hält (z. B. einen Port, ...) und nicht frei gibt. Vielleicht kannst Du mit lsof (oder gleichwertig) danach schauen.

Die Meldung kommt immer wieder nach jeden Login. D.h. ich müsste nach jeden Login manuell den Prozess killen. Hier nach einem Reboot.

1
2
3
4
5
6

ps axo stat,ppid,pid,comm | grep -w defunct
Z       2625    3873 rsyslogd <defunct>

ps -fp 3873
UID          PID    PPID  C STIME TTY          TIME CMD
root        3873    2625  0 11:33 ?        00:00:00 [rsyslogd] <defunct>

Ich habe mal nach dem Prozess 2625 geschaut. Hier wird ein Python script gestartet. start.py gibt es aber nicht unter /

1
2
3

ps -fp 2625
UID          PID    PPID  C STIME TTY          TIME CMD
root        2625    2404  0 11:33 ?        00:00:00 /usr/bin/python3 /start.py

Eine Idee was dies sein kann?

Ich habe bisher auch nichts "gekilled". Ich will mein laufendes System nicht zu stark "ärgern".

kkarsten62 schrieb:

Ich habe mal nach dem Prozess 2625 geschaut. Hier wird ein Python script gestartet. start.py gibt es aber nicht unter /

ps -fp 2625
UID          PID    PPID  C STIME TTY          TIME CMD
root        2625    2404  0 11:33 ?        00:00:00 /usr/bin/python3 /start.py

Eine Idee was dies sein kann?

Wie sind die Ausgaben von:

ps -fp 2404
sudo find / -iname '*start.py*'

?

lubux schrieb:

kkarsten62 schrieb: Wie sind die Ausgaben von:

ps -fp 2404
sudo find / -iname '*start.py*'

?

Ich glaube ich habe die Spur gefunden. Es führt zu meiner docker-compose Umgebung. Alle meine Applikationen auf dem Server habe ich über docker bzw. docker-compose realisiert. Ich bin aber noch nicht ganz sauber mit der "Restart" Anweisung in den docker-compose yml Dateien. Daher starten die Docker Container nicht sauber nach einem Reboot. Ich starte daher aktuell meine Docker-Umgebung nach einem Reboot manuell über eine kleines bash Script. Eine saubere Implementierung der "Restarts" steht noch auf meiner To-Do Liste.

Scheinbar versucht Docker etwas über rsyslogd ins Journal zu schreiben - dies schlägt wohl fehl.

Nach dem ich manuell die Docker-Umgebung gestartet habe ist der Zombie Prozess auch nicht mehr da. Hier der ganze Log:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

~$ ps axo stat,ppid,pid,comm | grep -w defunct
Z       1457    3144 rsyslogd <defunct>
~$ ps -fp 3144
UID          PID    PPID  C STIME TTY          TIME CMD
root        3144    1457  0 18:11 ?        00:00:00 [rsyslogd] <defunct>
~$ ps -fp 1457
UID          PID    PPID  C STIME TTY          TIME CMD
root        1457    1387  0 18:11 ?        00:00:00 /usr/bin/python3 /start.py
~$ ps -fp 1387
UID          PID    PPID  C STIME TTY          TIME CMD
root        1387       1  0 18:11 ?        00:00:00 /usr/bin/containerd-shim-runc-v2 -namespace moby -id 98012cf199614cd
~$ ps -fp 1
UID          PID    PPID  C STIME TTY          TIME CMD
root           1       0  1 18:11 ?        00:00:02 /sbin/init
==> Start meiner Docker-Umgebung
~$./down_up.sh 
~$ ps axo stat,ppid,pid,comm | grep -w defunct
==> Keine Ausgabe mehr

Danke lubux. Du hast mich auf die richtige Spur geführt. Ich halte das Thema noch ein paar Tage offen, sollte ich noch ein paar Erkenntnisse gewinnen können. Dann schließe ich das Thema ab. Nochmals vielen Dank.

Ich konnte das Thema etwas weiter eingrenzen:

Ich habe alle docker-compose Services auf

1

restart: always

gesetzt.

Die Services (verschiedene docker-compose) starte ich manuell in einer bestimmten Reihenfolge. Zuletzt den Reverse Proxy.

Folgende Erkenntnisse:

• Debian 10 TEST-Server: Alle Docker Services down und reboot ⇒ kein Zombie Prozess

• Ubuntu 20.04 PROD-Server: Alle Docker Services down und reboot ⇒ kein Zombie Prozess

• Debian 10 TEST-Server: Alle Docker Services laufen (up) und reboot ⇒ Alle Services sind wieder da, jedoch Zombie Prozess ist da, Alle Services funktionieren

• Ubuntu 20.04 PROD-Server: Alle Docker Services laufen (up) und reboot ⇒ Alle Services bis auf Proxy Service sind wieder da und Zombie Prozess ist da, Kein Service funktioniert (da ja kein Proxy Service)

Ich denke, dies ist nun ein Docker Thema. Ich schließe dies hier nun ab, untersuche es noch weiter und eröffne dann ggf. eine weiteres Thema im Docker Forum.