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

No meu caso particular, quero iniciar a remote-fsunidade depois que tudo glusterfscomeçar completamente.

Meus arquivos systemd:

glusterfs alvo:

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 alvo:

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 Gluster começar bem sucedido e eu quero montar Gluster sistema de arquivos via NFS, mas compartilhamento NFS da Gluster se prepara não imediatamente após glusterfs.servicecomeçou, mas alguns segundos depois, de modo geral remote-fsnão é capaz de montá-lo mesmo em relação Requirese Afterdirectivas.

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 está tudo OK, o sistema de arquivos remoto (/ stor) parece estar montado após o glusterfs ser iniciado, pois 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? O GlusterFS se preparou 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 determinística do processo de inicialização do systemd, às vezes (aproximadamente 1 de 10 inicializações) a montagem desse sistema de arquivos na inicialização é bem-sucedida.

Se a montagem do onboot não tiver êxito, posso efetuar login no servidor e montar manualmente o diretório / stor, para que o serviço NFS do Gluster pareça funcionar bem.

Então, como começar remote-fsdepois glusterfsd, ou seja, depois da Started GlusterFS brick processeslinha aparecer no log?

remote-fsparece ser um dos últimos alvos, por isso não consigo iniciá-lo depois de outro "contorno" que, de fato, não é obrigatório remote-fs.

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 compatível com SVG.

systemd-analyze plot > test.svg

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

Resolvi meu problema de montagem do NFS adicionando mountcomandos no /etc/rc.local. No entanto, não tenho certeza, ele funcionará com integração glusterd, vale a pena tentar uma solução rápida. Para fazer o systemd executar o rc.local, você deve atender à seguinte condição:

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

Como já sugerido por outros; Não tenho certeza se é realmente uma dependência do 'glusterfsd', em vez de um atraso geral em outra coisa, por exemplo, uma pesquisa de DNS que precisa ser bem-sucedida para resolver o '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 dependem do DNS possam iniciar com êxito.

A solução para isso foi ter um script 'ExecStartPre' que basicamente testa a disponibilidade das dependências específicas repetidas vezes, até que seja bem-sucedido (saída 0) ou exceda o tempo limite (saída 1).

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

Talvez você possa adicionar isso ao remote-fsalvo:

[Unit]
...
ConditionPathExists=/stor

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.