Systemd: inicia uma unidade após outra unidade REALMENTE iniciar

Question

No meu caso particular, eu quero começar a remote-fs unit depois que todo glusterfs começar completamente.

Meus arquivos systemd:

glusterfs target:

node04:/usr/lib/systemd/system # cat glusterfsd.service 
[Unit]
Description=GlusterFS brick processes (stopping only)
After=network.target glusterd.service

[Service]
Type=oneshot
ExecStart=/bin/true
RemainAfterExit=yes
ExecStop=/bin/sh -c "/bin/killall --wait glusterfsd || /bin/true"
ExecReload=/bin/sh -c "/bin/killall -HUP glusterfsd || /bin/true"

[Install]
WantedBy=multi-user.target

remote-fs target:

node04:/usr/lib/systemd/system # cat remote-fs.target 
[Unit]
Description=Remote File Systems
Documentation=man:systemd.special(7)
Requires=glusterfsd.service
After=glusterfsd.service remote-fs-pre.target
DefaultDependencies=no
Conflicts=shutdown.target

[Install]
WantedBy=multi-user.target

OK, todos os daemons do Gluster são bem-sucedidos e quero montar o sistema de arquivos Gluster via NFS, mas o compartilhamento NFS do Gluster fica pronto não imediatamente após glusterfs.service ser iniciado, mas alguns segundos depois, então remote-fs não consegue montá-lo mesmo em relação às diretivas Requires e After .

Vamos ver o log:

Apr 14 16:16:22 node04 systemd[1]: Started GlusterFS, a clustered file-system server.
Apr 14 16:16:22 node04 systemd[1]: Starting GlusterFS brick processes (stopping only)...
Apr 14 16:16:22 node04 systemd[1]: Starting Network is Online.
Apr 14 16:16:22 node04 systemd[1]: Reached target Network is Online.
Apr 14 16:16:22 node04 systemd[1]: Mounting /stor...

Aqui tudo está OK, o sistema de arquivos remoto (/ stor) parece estar montado depois que o glusterfs foi iniciado, já que significava estar de acordo com os arquivos da unidade ... Mas as próximas linhas são:

//...skipped.....
Apr 14 16:16:22 node04 systemd[1]: Started GlusterFS brick processes (stopping only).

O que? GlusterFS ficou pronto apenas para este momento! E então vemos:

//...skipped.....
Apr 14 16:16:23 node04 mount[2960]: mount.nfs: mounting node04:/stor failed, reason given by server: No such file or directory
Apr 14 16:16:23 node04 systemd[1]: stor.mount mount process exited, code=exited status=32
Apr 14 16:16:23 node04 systemd[1]: Failed to mount /stor.
Apr 14 16:16:23 node04 systemd[1]: Dependency failed for Remote File Systems.
Apr 14 16:16:23 node04 systemd[1]: Unit stor.mount entered failed state.

A montagem falhou porque o servidor NFS não estava pronto quando o systemd tentou montar o armazenamento.

Devido à natureza não determinista do processo de inicialização do systemd, às vezes (cerca de 1 de 10 inicializações) é possível montar esse sistema de arquivos na inicialização.

Se o onboot mount não foi bem-sucedido, posso efetuar login no servidor e montar manualmente o diretório / stor, portanto, o serviço NFS do Gluster parece funcionar bem.

Então, como iniciar remote-fs após glusterfsd , ou seja, após a linha Started GlusterFS brick processes aparecer no log?

remote-fs parece ser um dos últimos alvos, por isso não consigo iniciá-lo depois de outro destino de "solução alternativa" que, na verdade, não é exigido por remote-fs .

    

Answer 1

Você pode analisar a sequência de inicialização do systemd seguindo o comando. Visualize o arquivo de saída usando um navegador da Web de suporte a SVG.

systemd-analyze plot > test.svg

Essa plotagem fornecerá as estatísticas de tempo da última inicialização, que fornecerão um ponto de vista mais claro para o problema.

Eu resolvi meu problema de montagem do NFS adicionando mount comandos em /etc/rc.local . No entanto, não tenho certeza, funcionará com integração inteligente, vale a pena tentar uma solução rápida. Para fazer o systemd executar o rc.local, você deve satisfazer a seguinte condição:

# grep Condition /usr/lib/systemd/system/rc-local.service
ConditionFileIsExecutable=/etc/rc.d/rc.local

    

Answer 2

Como já sugerido por outros; Não tenho certeza se é realmente uma dependência de 'glusterfsd', em vez de um atraso geral em outra coisa, por exemplo, uma pesquisa de DNS que precisa ser bem-sucedida para resolver 'node4' e montar com êxito o compartilhamento NFS.

Corremos esse atraso porque a maioria de nossas configurações usa um resolvedor de validação local, que precisa estar disponível antes que outros serviços que dependam do DNS possam ser iniciados com êxito.

A solução para isso era ter um script 'ExecStartPre' que basicamente testa a disponibilidade das dependências específicas repetidamente, até ter sucesso (saída 0) ou tempo limite de tentativas (saída 1).

Certifique-se de personalizar fora do diretório main systemd lib, se puder. Alterar os arquivos do pacote significa que eles provavelmente serão sobrescritos na próxima atualização.

    

Answer 3

Talvez você possa adicionar isso a remote-fs target:

[Unit]
...
ConditionPathExists=/stor

    

Answer 4

Talvez algumas pesquisas possam ajudar. Isso é independente do systemd. Por exemplo, eu uso mysql -e ';' em um loop antes de fazer algo útil com o mysql.