it-swarm.com.de

Prozess mit PID 1 im Docker-Container kann nicht abgebrochen werden

Ich habe die folgende Docker-Datei zum Erstellen eines Containers mit einem PowerDNS-Recursor:

FROM debian:stretch-slim
ENV DEBIAN_FRONTEND noninteractive
RUN apt-get update && \
    apt-get install --no-install-recommends -y \
    pdns-recursor && \
    rm -rf /var/lib/apt/lists/* && \
    apt-get clean
COPY ./configuration/recursor.conf /etc/powerdns/recursor.conf
RUN chown -R :pdns /etc/powerdns/ && \
    chmod 0750 /etc/powerdns/ && \
    chmod 0640 /etc/powerdns/recursor.conf
EXPOSE 8699
ENTRYPOINT ["/usr/sbin/pdns_recursor", "--daemon=no"]

Mein recursor.conf Sieht folgendermaßen aus:

config-dir=/etc/powerdns
forward-zones=resolver1.opendns.com=208.67.222.222
hint-file=/usr/share/dns/root.hints
local-address=0.0.0.0
local-port=8699
quiet=yes
security-poll-suffix=
setgid=pdns
setuid=pdns

IPv6 ist auf dem Hypervisor deaktiviert.

Das Problem ist, dass Docker den Container mit docker stop recursor Nicht richtig stoppen kann. Nach einiger Zeit beendet der OOMKiller das Programm mit folgenden Informationen:

Exited (137) 2 seconds ago

Ich habe im Internet gesucht und die Signale 128 + 9 = 137 Bedeuten, dass ich nicht genügend RAM habe, was einfach nicht der Fall ist. Wenn ich docker exec -it recursor /bin/bash Ausführe und versuche, PID 1 (kill -9 -- 1) Im Container zu beenden, erhalte ich keine Reaktion - der Dienst wird einfach weiter ausgeführt, als wäre nichts passiert.

Ich habe auch versucht, den Recursor im Daemon-Modus zu starten - das gleiche Ergebnis.

Hat jemand eine Idee warum das so ist?

9
manifestor

Prozess mit PID 1 ist der Init-Prozess. Dies bleibt in einem PID-Namespace oder einem Container wahr: Diese PID 1 kann nicht mit SIGKILL beendet werden, da im Gegensatz zu any kein KILL Signalhandler definiert ist anderer Userland-Prozess.

Wenn du es wirklich töten willst, musst du es töten vom Host. Laufen auf dem Host (mit genügend Berechtigungen, wahrscheinlich root):

kill -KILL $(docker inspect --format '{{.State.Pid}}' containername)

Dadurch wird der gesamte Container heruntergefahren, da das Entfernen der PID 1 das Stoppen des Containers bedeutet. Bitte beachten Sie, dass ich auf den Titel der Frage geantwortet habe, aber nicht auf das zugrunde liegende Problem: Was verursacht OOM?.

UPDATE: wahrscheinlich einfacher zu bedienen docker kill , standardmäßig das Signal KILL. Das wäre:

docker kill containername

UPDATE2: Überzeugen Sie, dass PID 1 nicht mit SIGKILL (aka -9), gerade in einem Container (für das Beispiel muss der Benutzername aktiviert sein, andernfalls verwenden Sie einfach unshare --mount-proc --fork --pid als root).

erstes Terminal:

$ unshare --map-root-user --mount-proc --fork --pid
# echo $$
1
# pstree -p
bash(1)---pstree(88)
# kill -9 1
#

keine Wirkung

Auf einem zweiten Terminal:

$ pstree -p $(pidof unshare)
unshare(2023)───bash(2024)
$ kill -9 2024

erstes Terminal:

# Killed
$ 
15
A.B