editar: O problema foi que meu umask foi definido como 027 em vez do padrão 022. Veja abaixo para obter detalhes.
Estou enfrentando um (conjunto de) problemas desconcertantes em relação ao LXC que se manifesta em todo o sistema após ocorrer.
Ao iniciar/parar contêineres LXC, ocasionalmente o início ou parada irá travar indefinidamente. Quando isso acontece na inicialização, o processo do contêiner initestá em execução, mas não pode ser eliminado, mesmo usando kill -9. O contêiner nunca fica online e a única maneira de encerrar o processo é reinicializar o sistema.
O problema é que o sistema também não reinicia mais. Ao mesmo tempo que esse problema notei um problema ao executar update-initramfs, que também trava indefinidamente. Depois de encontrar isso:
https://unix.stackexchange.com/questions/428001/update-initramfs-hangs-on-debian-stretch
Concluí que, de fato, o synccomando (tanto o utilitário quanto a chamada do sistema) estão travados, fazendo com que o LXC não funcione, update-initramfstrave e o desligamento do sistema trave (como syncdeve ser feito antes de desmontar os sistemas de arquivos). Assim que o problema ocorrer, a chamada sync(do utilitário) a partir da linha de comando irá travar consistentemente indefinidamente. Tentei executá-lo, stracemas o rastreamento termina ao entrar na chamada do kernel e não consigo depurar mais. Eu monitorei os caches usandoessemas apenas paira na faixa <100kB.
Considerando syncque tem a ver com sistemas de arquivos, espero que haja algo errado com a maneira como o LXC está lidando com alguns sistemas de arquivos. Tenho outro servidor idêntico que não usa LXC, e depois de comparar a saída mountdesmontei os sistemas de arquivos não presentes naquele, sem sucesso. synccontinua pendurado.
Agora, com uma inicialização limpa e sem tocar no LXC,sync semprefunciona e continua funcionando. Por esse motivo e pelo fato de não estar vendo outros problemas, tenho certeza de que não há problemas reais de E/S. Além disso, quando um contêiner é iniciado com êxito, ele não parece ter problemas.
Eu vasculhei toda a Internet em relação a esse assunto, sem sucesso.
LXC 2.0.7-2+deb9u2 no Debian 9 (estável) com kernel 4.19.0-0.bpo.4-amd64 (embora isso tenha acontecido em outros kernels recentes também), com 2 SSDs em raid1 para /e 3 HDDs em raid5 ( mdadm) para /home. Os convidados são Debian 9 (stretch) ou 10 (buster), rodando como contêineres sem privilégios.Parece que reduzi tudo a isto: o problema não ocorreu para contêineres privilegiados.
Exemplo de configuração de contêiner convidado:
# 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
e mapeamentos subuid/gid:
# cat /etc/s*id
root:100000:1000000000
root:100000:1000000000
Exemplo de criação de contêiner, inicialização e parada com falha:
# 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.
Responder1
Acontece que o problema era minha umask menos permissiva que o padrão. O padrão do Debian é 022, que mudei na minha conta de usuário .bashrcpara 027 por motivos de segurança. Ao usar supara se tornar root, este umask é copiado de forma que todos lxc-*os comandos sejam executados com o umask 027. No entanto, isso resulta em um problema conhecido com o LXC, que por algum motivo ainda não foi corrigido (nos pacotes Debian, pelo menos? ).
Alterar o umask (na sessão ou modificando o .bashrc) me permite executar perfeitamente os contêineres que eu já tinha.
Recursos:
https://github.com/lxc/lxc/issues/2277(não tenho certeza se este é o mesmo problema)