Em que ponto os cgroups são inicializados para o systemd?

Question

Então, para encurtar a história, estou tentando fazer o systemd funcionar com uma instalação do Arch, mas sem executar o systemd do init. Isso significa que eu estou inicializando em um sistema que não está executando o systemd e, em seguida, tentando iniciar o systemd nele.

O problema que estou enfrentando diz respeito aos cgroups - durante a inicialização, o systemd reclama sobre a falta / sys / fs / cgroup / systemd como um cgroup e, portanto, é executado com funcionalidade reduzida, pois acha que os cgroups não estão disponíveis. Isso causa problemas em qualquer ferramenta que use o D-Bus para se comunicar com o systemd.

Executando o systemd normalmente (rodando como PID 1) os cgroups são criados corretamente e o systemd trabalha completamente. No entanto, quando é executado em um sistema já inicializado, nenhum cgroup é criado. O que eu quero saber é em que ponto durante o processo de inicialização é / sys / fs / cgroup / systemd criado / montado, e como posso replicar isso em um sistema já em execução? Posso confirmar que não é / sbin / init que cria o cgroup, já que a execução produz os mesmos resultados.

Na falta disso, onde devo começar a procurar no código-fonte do systemd? Ou talvez haja uma lista de discussão em que eu possa obter respostas melhores diretamente dos desenvolvedores?

    

Answer 1

Certo, então depois de pesquisar o código-fonte de systemd , encontrei o ponto em que o cgroup systemd é criado. Em src/core/main.c dentro de main() , a função mount_setup_early() é chamada, mas somente se systemd estiver sendo executado como PID 1 e não em um contêiner. mount_setup_early() é definido em src/core/mount-setup.c e simplesmente monta certos sistemas de arquivos essenciais como /proc , /dev e mais importante /sys/fs/cgroup/systemd .

O fato de que eu estava tentando executar systemd como PID! = 1 significava que essa função nunca foi executada. Portanto, mais abaixo em main() test_cgroups() é executado e falha, pois /sys/fs/cgroup/systemd não está montado. Como não há como falsificar este processo 'PID (ou pelo menos, não aquele que eu conheço ou estou disposto a tentar), a solução é montar manualmente esses sistemas de arquivos antes de executar systemd . Pelo menos, essa é a teoria.

Outro efeito colateral interessante desta aventura é um pouco mais compreensivo em como as hierarquias nomeadas funcionam com cgroups. Há pouca documentação disponível para cgroups, especialmente sobre como exatamente as hierarquias nomeadas funcionam. Para montar uma hierarquia nomeada de maneira semelhante a como systemd , execute:

mount -t cgroup cgroup -o none,name=<name> <mountpoint>

Isso fornece uma hierarquia completamente em branco semelhante à hierarquia name=systemd montada em /sys/fs/cgroup/systemd . Se você deseja ligar subsistemas a essa hierarquia, substitua none pelos subsistemas desejados.

    

Answer 2

systemd é um sistema init, mesmo se você conseguir executá-lo como PID != 1 , certamente haverá muitas coisas dando errado (por exemplo, qual init processo será responsável por iniciar / parar processos?)

Existem maneiras de usar cgroups sem usar systemd , se é isso que você precisa, pois elas são implementadas no kernel, não em systemd , que é "apenas" usando esses recursos.

De acordo com as informações dos desenvolvedores, a página da web systemd lista todos os tipos de recursos, incluindo várias listas de discussão , a URL do repositório git e a documentação do projeto, que é muito abrangente.