LXC start/stop hangt en daarna filesystem sync ook

[geez]

edit: Issue is gevonden; een niet default umask van 027 ipv de default 022 leidt tot een bekend probleem met LXC. Zie een latere post voor meer info.

Naar aanleiding van mijn topic op superuser ook een poging bij het collectieve GoT brein.

In een move van mijn services van native naar LXC containers kom ik met grote regelmaat hangende containers tegen, bij het starten dan wel stoppen van containers (meestal bij stoppen). Op het moment dat dat gebeurt hangt het lxc-stop commando oneindig, en het init proces van de guest draait nog (als uid 200000, want unprivileged container) en is niet te killen, inclusief door kill -9. Overigens als de start van een container wél werkt, lijkt de container het prima te doen.

Tegelijkertijd heb ik gemerkt dat update-initramfs begon te hangen. Bij het vinden van dit topic kwam ik erachter dat de sync operatie hangt - zowel de utility als de system call. Het systeem sluit ook niet meer af - vermoedelijk omdat een sync uitgevoerd wordt alvorens de filesystems te unmounten.

Op een schone boot waar ik LXC nooit aanraak werkt alles perfect, inclusief sync, en dit blijft zo. Omdat er verder ook geen andere issues zijn ben ik overtuigd dat er geen daadwerkelijke I/O issues zijn. Hier staat ook een voorbeeld container config (vrij standaard). Mijn vermoeden is dan ook dat lxc/lxcfs iets doet met filesystems, waar sync vervolgens op stuk gaat. Ik heb strace sync gedraaid, maar die eindigt bij het moment dat de kernel call gedaan wordt, en ik weet nu niet hoe verder.

Voorbeeld container config:

code:

# 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

De aanwezig van de mount heeft geen invloed. Na wat verder testen lijkt het erop dat de issue specifiek is voor unprivileged containers. Bij een privileged container deed het zich niet voor.

LXC 2.0.7-2+deb9u2 op Debian 9 (stable) met kernel 4.19.0-0.bpo.4-amd64 (zelfde probleem op andere recente kernels)
2 SSD's in raid1 voor / en 3 HDD's in raid5 (mdadm) op /home.
Guests zijn Debian 9 (stretch), unprivileged. Één gebruikt een share mount maar dat lijkt niet uit te maken maakt niet uit.

[ Voor 35% gewijzigd door geez op 23-05-2019 14:09 ]

[dcm360]

Het is wel soort van een bekend probleem, ik en anderen hebben er ook last van. Ergens in de kernel lijkt iets niet lekker te gaan, maar wat precies is niet echt duidelijk. Op het forum van Proxmox loopt er een topic over https://forum.proxmox.com...c-becomes-unusable.41264/

[geez]

Ik zie in dat topic verschillende problemen; eerst iets m.b.t. een clone operatie, en aan het eind m.b.t. netwerk. Mijn kernel is veel nieuwer dan versies met de issue daar genoemd. (4.13/4.14 vs 4.19). Ik zie niets over problemen met sync, of niet in staat zijn te rebooten (iets dat uitvoerig besproken is omdat dat een manier was om de zaak te herstellen). Hoe kom je erbij dat het hetzelfde issue is?

[geez]

Na nog een hoop meer zoekwerk heb ik het probleem getraceerd. Na mijn constatering dat de issue zich alleen voordeed bij unprivileged containers, en het zien van meer nobody:nogroup folders in / van de container (vanuit de container) dan de bedoeling is, ben ik uiteindelijk op het spoor gekomen van een umask issue.

De default umask van Debian is 022, wat ik voor mijn gebruiker heb gewijzigd (in .bashrc) naar 027 om veiligheidsredenen. Door met su vervolgens root te worden, werd deze overgenomen, en alle daarna uitgevoerde lxc-* commando's werden dus uitgevoerd in een omgeving met umask 027. Dit resulteerde in een bekend issue met LXC, wat jaren na dato om de één of andere reden nog steeds niet opgelost is (in de Debian packages, althans..).

Door de umask (runtime of in .bashrc) te wijzingen naar 022 laat me de bestaande containers starten en stoppen zonder problemen.

Resources:

https://discuss.linuxcont...temd-process-on-host/1079

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

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

[ Voor 3% gewijzigd door geez op 23-05-2019 14:24 ]