But, isn't the initramfs unmounted once systemd starts?
Não. O sistema de arquivos initramfs na verdade não pode ser desmontado .
Pelo menos se o initramfs for implementado usando systemd , ele chama umount() , mas passa o sinalizador MNT_DETACH . Veja também umount -l .
(Esse modo de umount() não é evitado quando há arquivos abertos. Apenas "desanexa" o sistema de arquivos initramfs de seu ponto de montagem, removendo-o da tabela de montagem ( /proc/mounts etc). Qualquer arquivo aberto pode continuar sendo usado. Uma vez que todos os arquivos abertos estejam fechados, então o kernel irá terminar de desmontar o sistema de arquivos).
Where is the filesystem that "Root Storage Daemons" run from? And what does it look like from their point of view?
O espírito de "RootStorageDaemons" diz que eles continuam sendo executados dentro do desconectado initramfs.
Além de desanexar a montagem, MNT_DETACH desanexa todas as montagens secundárias. Assim, os daemons de armazenamento raiz não verão sistemas de arquivos de API críticos, incluindo / dev e / proc. Isso é bem brutal:
# unshare -m
\# umount -l /
\# findmnt
findmnt: can't read /proc/mounts: No such file or directory
\# ls /dev
\#
Depois de usar MNT_DETACH, systemd no initramfs continua a corresponder ao comando mais tradicional switch_root , deletando unlink () em todos os arquivos do initramfs. (A função systemd é chamada rm_rf_children() - efetivamente faz rm -rf * . Como de costume, qualquer arquivo aberto - incluindo os arquivos executáveis e de biblioteca dos daemons em execução - continuará funcionando. Quando a última referência ao arquivo for fechada, seu armazenamento será liberado pelo kernel).
Se for verdade, isso seria bastante interessante; seria uma boa proteção contra um bug em um RootStorageDaemon que abriu um arquivo no sistema de arquivos raiz. Também poderia ser uma proteção parcial contra chamadas RPC por meio de sockets em /run e se tornar dependente de daemons em execução no sistema de arquivos raiz. Fazer qualquer uma dessas coisas poderia causar um impasse (dependência circular).
No entanto, em fato , se você olhar para /proc/$PID/root de um daemon de armazenamento raiz, ele provavelmente apontará para o sistema de arquivos raiz principal, não para o initramfs. Então, por que isso aconteceria e como o sistema trabalha diante disso?
Isso acontece porque o initramfs usa pivot_root() para alternar para o sistema de arquivos raiz. Além de modificar a tabela de montagem, pivot_root() atualmente verifica a raiz e o diretório de trabalho atual ( /proc/$PID/root e /proc/$PID/cwd ) de todos os processos. Se qualquer uma delas corresponder ao diretório raiz do sistema de arquivos raiz antigo (initramfs), elas serão substituídas pela nova. Isso é documentado como um detalhe de implementação de pivot_root() , que os programas não devem confiar.
<del> O sistema funciona porque pivot_root() também é como systemd é capaz de alternar de volta para um initramfs. Assim, as referências ao sistema de arquivos raiz são substituídas novamente, com referências aos novos initramfs brilhantes. </del>
(Também é provável que o /run tmpfs no novo initramfs brilhante seja passado de /run no sistema de arquivos raiz. O que, por sua vez, foi passado do initramfs. Nesse caso, acho que seria permitir que o initramfs de desligamento se comunique com o RootStorageDaemon, se o daemon abrir um soquete em /run como parte de sua sequência de inicialização.)