Preguiçoso desmontar unidades de cadeia raiz

Question

Eu criei uma jaula raiz contendo rpm e yum (centos 7.5) para instalar algum software no sistema original.

Fluxo de trabalho

• Monte sys, proc, dev para a cadeia raiz
• Monte a raiz do sistema original "/" na cadeia. Isso é importante, pois uso a cadeia raiz para instalar o software no sistema básico
• Monte sys, proc, dev do sistema original dentro da raiz do sistema original no rootJail, por ex. mount / proc / rootJail / originalRoot / proc que é necessário para alguns softwares que estão sendo instalados
• insira a cadeia raiz, instale o software, saia da cadeia raiz
• desmontar sys, proc, dev da cadeia raiz
• umount sys, proc, dev do sistema original dentro da cadeia raiz
• desmonte a raiz dos sistemas originais da cadeia raiz (é onde ela falha)

umount: /rootJail/originalRoot: target is busy. (In some cases useful info about processes that use the device is found by lsof(8) or fuser(1))

Então eu basicamente posso desmontar tudo, exceto a raiz do próprio sistema original. Eu preciso para que, a fim de remover a cadeia de raiz que é obrigatória.

O problema é que muitos processos estão sendo iniciados após a instalação do software dentro da cadeia raiz. É por isso que me diz que o alvo está ocupado. Matar todos estes processos não é possível, pois isso também mata o sistema. Parece que esses processos estão vinculados ao rootJail, em vez do sistema real, mesmo quando o caminho da instalação está correto. Além disso, depois de uma reinicialização, tudo está funcionando perfeitamente (Pior caso: remova a pasta aqui)

Eu já tentei fazer uma desmontagem preguiçosa que basicamente funciona. Eu posso remover o rootJail e não parece prejudicar o sistema original que foi montado dentro

Minha pergunta é: isso é seguro? ou existem outras soluções de como desmontar essa pasta?

    

Answer 1

Assim, você parece querer que esses processos continuem sendo executados indefinidamente, ou seja, eles são processos de serviço - que foram iniciados dentro do ambiente chroot aninhado. Isso sugere que você está gerando um processo de serviço a partir do seu shell, ao invés do systemd.

Em geral, isso é ruim e você vai querer evitá-lo.

O CentOS 7 usa systemd , sendo executado como PID 1 e gerenciando serviços do sistema. Obviamente, o PID 1 do sistema principal não roda dentro do seu chroot. Normalmente, quando você solicita o início de um processo de serviço do sistema, ele é retirado do PID 1 para fornecer um ambiente clean (personalizado de acordo com o arquivo .service unit relevante). (Isso inclui scripts herdados do sysvinit. Eles são importados para arquivos .service gerados automaticamente).

(Para ilustrar isto mais adiante, é tecnicamente possível executar um chroot onde você monta o bind em um socket para se comunicar com o systemd, e usa comandos dentro do chroot para manipular os serviços do sistema host).

O problema não é apenas que sua abordagem perde os benefícios do systemd. Isso significa que você confunde o serviço systemd, se houver um para esse daemon. Por exemplo, o serviço pode mostrar como não iniciado ( service foo status ). Se mais tarde você tentar service foo restart ... systemd não saberá que existe um daemon para parar, e ele tentará iniciar uma instância do daemon segundo . Isso é um pouco confuso para depurar! Muitas vezes você vai ter um bom erro imediato sobre não ser capaz de iniciar seu servidor web porque já existe outro programa escutando na porta TCP 80 :), mas em outros casos você pode acabar com duas instâncias diferentes de um daemon que acham que deveriam ser o único, causando erros que demoram mais para perceber.