LXC-Start/Stopp-Hänger und Dateisystem-Synchronisations-Hänger

LXC-Start/Stopp-Hänger und Dateisystem-Synchronisations-Hänger

Bearbeiten: Das Problem war, dass meine Umask auf 027 statt auf den Standardwert 022 eingestellt war. Einzelheiten siehe unten.

Ich habe eine Reihe verwirrender Probleme im Zusammenhang mit LXC, die sich nach ihrem Auftreten im gesamten System bemerkbar machen.

initBeim Starten/Stoppen von LXC-Containern kommt es gelegentlich vor, dass der Start oder Stopp auf unbestimmte Zeit hängen bleibt. Wenn dies beim Start geschieht, läuft der Prozess des Containers zwar, kann aber nicht beendet werden, selbst mit kill -9. Der Container kommt nie online und die einzige Möglichkeit, den Prozess zu beenden, ist ein Systemneustart.

Das Problem ist, dass das System auch nicht mehr neu gestartet wird. Gleichzeitig mit diesem Problem ist mir ein Problem beim Ausführen von aufgefallen update-initramfs, das ebenfalls auf unbestimmte Zeit hängen bleibt. Nachdem ich Folgendes gefunden hatte: https://unix.stackexchange.com/questions/428001/update-initramfs-hangs-on-debian-stretch Ich bin zu dem Schluss gekommen, dass der syncBefehl (sowohl das Dienstprogramm als auch der Systemaufruf) tatsächlich hängen bleibt, was dazu führt, dass LXC nicht funktioniert, update-initramfshängen bleibt und das Herunterfahren des Systems hängen bleibt (was syncvor dem Unmounten von Dateisystemen erfolgen sollte). Sobald das Problem auftritt, syncbleibt der Aufruf (des Dienstprogramms) von der Befehlszeile aus dauerhaft und auf unbestimmte Zeit hängen. Ich habe versucht, es auszuführen, straceaber die Ablaufverfolgung endet, wenn ich in den Kernel-Aufruf gehe, und ich kann nicht weiter debuggen. Ich habe die Caches überwacht mitDasaber es schwankt gerade so im Bereich <100 kB.

Da es syncmit Dateisystemen zu tun hat, gehe ich davon aus, dass etwas mit der Art und Weise nicht stimmt, wie LXC mit einigen Dateisystemen umgeht. Ich habe einen anderen identischen Server, der LXC nicht verwendet, und nachdem mountich die Ausgabe verglichen hatte, habe ich die auf diesem Server nicht vorhandenen Dateisysteme ausgehängt, ohne Erfolg. synchängt weiterhin.

Nun, bei einem sauberen Neustart, ohne LXC zu berühren,sync stetsfunktioniert und funktioniert weiterhin. Aus diesem Grund und weil ich keine anderen Probleme sehe, bin ich sicher, dass es keine tatsächlichen E/A-Probleme gibt. Auch wenn ein Container erfolgreich gestartet wird, scheint es keine Probleme zu geben.

Ich habe das Internet zu diesem Thema umfassend durchforstet, jedoch ohne Erfolg.

LXC 2.0.7-2+deb9u2 auf Debian 9 (stabil) mit Kernel 4.19.0-0.bpo.4-amd64 (obwohl dies auch in anderen aktuellen Kerneln auftrat), mit 2 SSDs in Raid1 für /und 3 HDDs in Raid5 (mdadm) für /home. Gäste sind Debian 9 (Stretch) oder 10 (Buster) und laufen als unprivilegierte Container.Ich scheine es auf Folgendes eingegrenzt zu haben: Das Problem trat bei privilegierten Containern nicht auf.

Beispielkonfiguration eines Gastcontainers:

# Template used to create this container: /usr/share/lxc/templates/lxc-download

# Distribution configuration
lxc.include = /usr/share/lxc/config/debian.common.conf
lxc.include = /usr/share/lxc/config/debian.userns.conf
lxc.arch = linux64

# Container specific configuration
lxc.id_map = u 0 200000 100000
lxc.id_map = g 0 200000 100000

# Network configuration
#lxc.network.type = empty
lxc.network.type = veth
lxc.network.link = lxcbr0
lxc.network.flags = up
lxc.network.hwaddr = 00:16:3e:e9:4a:e7
lxc.rootfs = /var/lib/lxc/somename/rootfs
lxc.rootfs.backend = dir
lxc.utsname = somename

# Mounts
lxc.mount.entry = /var/lib/lxc/temp mnt/temp none bind 0 0

und Subuid/Gid-Zuordnungen:

# cat /etc/s*id
root:100000:1000000000
root:100000:1000000000

Beispiel für Containererstellung, -start und fehlgeschlagenen Stopp:

# lxc-create -n test -t download
...
Distribution: debian
Release: stretch
Architecture: amd64

Downloading the image index
Downloading the rootfs
Downloading the metadata
The image cache is now ready
Unpacking the rootfs

---
You just created a Debian stretch amd64 (20190522_05:24) container.

# lxc-ls -f
NAME          STATE   AUTOSTART GROUPS IPV4 IPV6 
test          STOPPED 0         -      -    -    

# lxc-start -n test

# lxc-ls -f
NAME          STATE   AUTOSTART GROUPS IPV4 IPV6 
test          RUNNING 0         -      -    -    

# lxc-attach -n test
root@test:/# ls -alh /
total 68K
drwxr-xr-x  21 root   root    4.0K May 22 05:26 .
drwxr-xr-x  21 root   root    4.0K May 22 05:26 ..
drwxr-xr-x   2 root   root    4.0K May 22 05:26 bin
drwxr-xr-x   2 root   root    4.0K Mar 28 09:12 boot
drwxr-xr-x   4 root   root     400 May 22 09:26 dev
drwxr-xr-x  42 root   root    4.0K May 22 09:24 etc
drwxr-xr-x   2 root   root    4.0K Mar 28 09:12 home
drwxr-xr-x   9 root   root    4.0K May 22 05:25 lib
drwxr-xr-x   2 root   root    4.0K May 22 05:25 lib64
drwxr-xr-x   2 root   root    4.0K May 22 05:25 media
drwxr-xr-x   2 root   root    4.0K May 22 05:25 mnt
drwxr-xr-x   2 root   root    4.0K May 22 05:25 opt
dr-xr-xr-x 225 nobody nogroup    0 May 22 09:26 proc
drwx------   2 root   root    4.0K May 22 05:25 root
drwxr-xr-x   3 root   root      60 May 22 09:26 run
drwxr-xr-x   2 root   root    4.0K May 22 05:26 sbin
drwxr-xr-x   2 root   root    4.0K May 22 05:25 srv
dr-xr-xr-x  13 nobody nogroup    0 May 19 17:07 sys
drwxrwxrwt   2 root   root    4.0K May 22 05:25 tmp
drwxr-xr-x  10 root   root    4.0K May 22 05:25 usr
drwxr-xr-x  11 root   root    4.0K May 22 05:25 var
root@test:/# exit

# lxc-ls -f
NAME          STATE   AUTOSTART GROUPS IPV4 IPV6 
debian_buster STOPPED 0         -      -    -    
rtorrent      STOPPED 0         -      -    -    
test          RUNNING 0         -      -    -    

# lxc-stop -n test
^C

# lxc-stop -n test
... continues to hang ...
# ^C
# sync
^C^C^Z^X^C^Z^X^C^Z^C^Z^X^C
... won't die.

Antwort1

Wie sich herausstellte, war das Problem meine weniger freizügige Umask als die Standard-Umask. Debians Standard ist 022, was ich in meinen Benutzerkonten .bashrcaus Sicherheitsgründen auf 027 geändert habe. Wenn ich mich suals Root anmelden möchte, wird diese Umask kopiert, sodass alle lxc-*Befehle mit der Umask 027 ausgeführt werden. Dies führt jedoch zu einem bekannten Problem mit LXC, das aus irgendeinem Grund noch immer nicht behoben wurde (zumindest in den Debian-Paketen?).

Durch Ändern der Umask (in der Sitzung oder durch Ändern der .bashrc) kann ich die Container, die ich bereits hatte, problemlos ausführen.

Ressourcen:

https://discuss.linuxcontainers.org/t/cannot-stop-unprivileged-container-not-even-kill-9-its-systemd-process-on-host/1079

https://github.com/lxc/lxc/issues/2277(nicht sicher, ob das dasselbe Problem ist)

https://github.com/lxc/lxc/issues/1403

https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1642767

verwandte Informationen