
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.
init
Beim 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 sync
Befehl (sowohl das Dienstprogramm als auch der Systemaufruf) tatsächlich hängen bleibt, was dazu führt, dass LXC nicht funktioniert, update-initramfs
hängen bleibt und das Herunterfahren des Systems hängen bleibt (was sync
vor dem Unmounten von Dateisystemen erfolgen sollte). Sobald das Problem auftritt, sync
bleibt der Aufruf (des Dienstprogramms) von der Befehlszeile aus dauerhaft und auf unbestimmte Zeit hängen. Ich habe versucht, es auszuführen, strace
aber 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 sync
mit 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 mount
ich die Ausgabe verglichen hatte, habe ich die auf diesem Server nicht vorhandenen Dateisysteme ausgehängt, ohne Erfolg. sync
hä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 .bashrc
aus Sicherheitsgründen auf 027 geändert habe. Wenn ich mich su
als 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://github.com/lxc/lxc/issues/2277(nicht sicher, ob das dasselbe Problem ist)