Estou tentando iniciar um contêiner LXC e executar um comando dentro dele. O problema é que mesmo que o contêiner esteja no estado RUNNING, ele não concluiu toda a inicialização. Isso produz problemas com /tmp (e, eu acho, com outras inicializações).
Isso pode ser ilustrado com esta sequência de chamadas que cria um contêiner, inicia-o, aguarda seu estado RUNNING e executa alguns comandos; os comandos criam um arquivo /tmp/hello, mostram um diretório, esperam um pouco e mostram novamente o diretório:
lxc-clone -B overlayfs -s -o vm -n c1 ; lxc-start -n c1 ; lxc-wait -n c1 -s RUNNING ; lxc-attach -n c1 -- su -c "touch /tmp/hello; ls -la /tmp; sleep 5; ls -la /tmp" slave ; lxc-stop -n c1 ; lxc-destroy -n c1
cuja saída é
Created container c1 as snapshot of vm total 16 drwxrwxrwt 1 root root 4096 May 24 09:37 . drwxr-xr-x 1 root nogroup 4096 May 24 09:37 .. drwxrwxrwt 2 root root 4096 May 22 21:19 .ICE-unix drwxrwxrwt 2 root root 4096 May 22 21:19 .X11-unix -rw-rw-r-- 1 slave slave 0 May 24 09:37 hello total 16 drwxrwxrwt 1 root root 4096 May 24 09:37 . drwxr-xr-x 1 root nogroup 4096 May 24 09:37 .. drwxrwxrwt 2 root root 4096 May 24 09:37 .ICE-unix drwxrwxrwt 2 root root 4096 May 24 09:37 .X11-unix
e mostra que o arquivo /tmp/hello foi excluído por algum script de inicialização.
Como esperar dentro do container até que o sistema esteja totalmente inicializado? Além disso, como fazer isso de fora do contêiner?
Responder1
Para um contêiner executado no systemd, parece que funciona bem:
lxc-attach -n [CONTAINER NAME] -- systemctl isolate multi-user.target
Você provavelmente poderia aplicar a mesma lógica para um contêiner baseado sysvinitem ou upstart(executar um comando que bloqueia até que um nível de execução seja atingido), mas eu não poderia dizer quais comandos podem fazer isso na minha cabeça.
Responder2
No meu caso, considero um contêiner LXC "pronto" quando tiver conectividade de rede (por exemplo, para que comandos como apt updatefuncionem dentro de um script de configuração de contêiner LXC).
No Debian 11 bullseye como host lxc, com um contêiner Debian 11 bullseye lxc, tive sucesso em aproveitar o seguinte padrão:
lxc-unpriv-start -n "$LXC_CONTAINER"
lxc-wait -n "$LXC_CONTAINER" -s RUNNING
# the lxc-wait RUNNING state is not that useful;
# a container is already considered RUNNING even though the network is not yet up
# the following command blocks until the container's network is up
lxc-unpriv-attach -n "$LXC_CONTAINER" -- systemctl start systemd-networkd-wait-online.service
# when the script reaches this part, the lxc container's network probably is completely up and running
lxc-unpriv-attach -n "$LXC_CONTAINER" -- apt update
# ...
A systemctl start systemd-networkd-wait-online.serviceparte relevante:
systemd-networkd-wait-online.serviceé um serviço systemd fornecido imediatamente que requer apenas onetwork-online.target(ou assim eu entendo, pelo menos).
Portanto, executando systemctl start systemd-networkd-wait-online.serviceblocos até que a rede esteja ativa.