Gerador e montagens SystemD SysV

Question

Portanto, systemd-sysv-generator converte arquivos init.d estilo antigo em arquivos de serviço systemd. Mas isso pode acontecer antes que todas as montagens tenham sido montadas.

Eu tenho alguns softwares comerciais herdados que residem no / opt, que é um ponto de montagem separado. Ele cria um link simbólico de /etc/init.d/their_service para um arquivo em / opt

Assim, quando o servidor inicializa, systemd-sysv-generator ainda não consegue ler o arquivo vinculado e não consegue criar um serviço e, portanto, não consegue iniciar o serviço.

Como o software legado é gerenciado por outra equipe e eles têm o poder de atualizá-lo por conta própria, não quero começar a copiar o arquivo de / opt e substituir o link simbólico. Ou pior, tente reescrever isso em um serviço systemd.

Existe alguma maneira de ter systemd-sysv-generator fire após opt.mount ?

    

Answer 1

Graças à dica de euwaseatenbyagrue para ler link Encontrei esta seção

initrd-fs.target

systemd-fstab-generator(3) automatically adds dependencies of type Before= to sysroot-usr.mount and all mount points found in /etc/fstab that have x-initrd.mount and not have noauto mount options set.

Então, minha correção foi fazer o seguinte

1. Edite /etc/fstab para ter a opção x-initrd.mount para meu ponto de montagem / opt

/dev/mapper/rootvg-opt /opt ext4 nodev,x-initrd.mount 0 0

2. Edite /etc/default/grub para listar o ponto de montagem extra em GRUB_CMDLINE_LINUX

GRUB_CMDLINE_LINUX="rd.lvm.lv=rootvg/root rd.lvm.lv=rootvg/swap rd.lvm.lv=rootvg/usr rd.lvm.lv=rootvg/opt ipv6.disable=1 rhgb quiet"

3. Reconstruir a inicialização

grub2-mkconfig -o /boot/grub2/grub.conf

dracut -f

Essas etapas combinadas fazem com que o SystemD monte / opte corretamente no início da inicialização e seja bem-sucedido com systemd-sysv-generator

    

Answer 2

Uma opção pode ser criar um drop-in para seu serviço, que especifica dependências / pedidos.

Por exemplo:

$ sudo mkdir /etc/systemd/system/their_service.service.d
$ sudo vi /etc/systemd/system/their_service.service.d/50-require_mounts.conf
[Unit]
Wants=network.target remote-fs.target
After=network.target remote-fs.target

No entanto, o script SysV pode ser adaptado para classificar esse problema ( link ) :

remote-fs.target Similar to local-fs.target, but for remote mount points.

systemd automatically adds dependencies of type After= for this target unit to all SysV init script service units with an LSB header referring to the "$remote_fs" facility.