editar: El problema fue que mi umask estaba configurada en 027 en lugar del valor predeterminado de 022. Consulte a continuación para obtener más detalles.
Estoy experimentando un (conjunto de) problemas desconcertantes con respecto a LXC que se manifiestan en todo el sistema después de ocurrir.
Al iniciar/detener contenedores LXC, ocasionalmente el inicio o la parada se bloquearán indefinidamente. Cuando esto sucede al inicio, el proceso del contenedor initse está ejecutando pero no se puede eliminar, incluso usando kill -9. El contenedor nunca se conecta y la única forma de finalizar el proceso es reiniciar el sistema.
La cuestión es que el sistema tampoco se reiniciará más. Al mismo tiempo que surgía este problema, noté un problema al ejecutar update-initramfs, que también se bloquea indefinidamente. Después de encontrar esto:
https://unix.stackexchange.com/questions/428001/update-initramfs-hangs-on-debian-stretch
He llegado a la conclusión de que, de hecho, el synccomando (tanto la utilidad como la llamada al sistema) se bloquean, lo que provoca que LXC no funcione, update-initramfsse cuelgue y el sistema se apague (como syncse debe hacer antes de desmontar los sistemas de archivos). Una vez que ocurre el problema, llamar sync(a la utilidad) desde la línea de comando se bloqueará indefinidamente. Intenté ejecutarlo stracepero el seguimiento finaliza cuando ingresa a la llamada del kernel y no puedo depurar más. He monitoreado los cachés usandoestepero simplemente ronda el rango <100 kB.
Teniendo en cuenta syncque tiene que ver con los sistemas de archivos, espero que haya algún problema con la forma en que LXC maneja algunos sistemas de archivos. Tengo otro servidor idéntico que no usa LXC, y después de comparar el resultado, mountdesmonté los sistemas de archivos que no estaban presentes en ese, sin éxito. synccontinúa colgado.
Ahora, con un arranque limpio y sin tocar LXC,sync siemprefunciona y sigue funcionando. Por esta razón y por el hecho de que no veo otros problemas, estoy seguro de que no hay problemas reales de E/S. Además, cuando un contenedor se inicia correctamente, no parece tener ningún problema.
He buscado en Internet por todas partes sobre este tema, sin éxito.
LXC 2.0.7-2+deb9u2 en Debian 9 (estable) con kernel 4.19.0-0.bpo.4-amd64 (aunque también sucedió en otros kernels recientes), con 2 SSD en raid1 /y 3 HDD en raid5 ( mdadm) para /home. Los invitados son Debian 9 (stretch) o 10 (buster), ejecutándose como contenedores sin privilegios.Parece que lo he reducido a esto: el problema no ocurrió con los contenedores privilegiados.
Ejemplo de configuración de contenedor invitado:
# 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
y mapeos subuid/gid:
# cat /etc/s*id
root:100000:1000000000
root:100000:1000000000
Ejemplo de creación, inicio y detención fallida de un contenedor:
# 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.
Respuesta1
Resulta que el problema fue mi umask menos permisiva que la predeterminada. El valor predeterminado de Debian es 022, que he cambiado en mi cuenta de usuario .bashrca 027 por razones de seguridad. Al usarse supara convertirse en root, esta umask se copia de manera que todos lxc-*los comandos se ejecuten con umask 027. Sin embargo, esto da como resultado un problema conocido con LXC, que por alguna razón aún no se ha solucionado (¿al menos en los paquetes de Debian? ).
Cambiar la umask (en la sesión o modificando el .bashrc) me permite ejecutar bien los contenedores que ya tenía.
Recursos:
https://github.com/lxc/lxc/issues/2277(no estoy seguro de que sea el mismo problema)