Encontramos o seguinte problema em nossa empresa. Temos vários servidores Red Hat Enterprise Linux nos quais o "SAP HANA S / 4" está em execução.
Criamos um serviço systemd para iniciar e parar automaticamente o daemon, para que não precisemos interagir manualmente com o sistema em uma reinicialização ou desligamento.
Autostart funciona bem, mas parece haver um problema em parar o daemon corretamente no desligamento. Os daemons estão sendo executados com outro usuário (individual para cada servidor). Parece que o systemd começa a matar as sessões do usuário antes que o serviço real seja parado; Como resultado, o serviço não será interrompido adequadamente.
Serviço
[Unit]
Description=saphana
After=remote-fs.target user.slice sapinit.service multi-user.target
Requires=user.slice
[Service]
KillMode=none
Type=oneshot
ExecStart=/hana/source/scripts/sapHanaControl.pl start
ExecStop=/hana/source/scripts/sapHanaControl.pl stop
RemainAfterExit=yes
[Install]
WantedBy=multi-user.target
O script que é chamado em ExecStart e ExecStop basicamente executa o seguinte comando.
No início:
"sudo -u $username csh -c "sapcontrol -nr $instance -function Start"
Na parada:
"sudo-u $ username csh -c" sapcontrol -nr $ instance -function Parar "
Log de desligamento
A saída do log do Systemd mostra o seguinte:
Jun 20 16:23:05 host123 systemd[1]: Stopping Session c4 of user **userxy**.
Jun 20 16:23:05 host123sapHanaControl.pl[15003]: sudo -u **userxy** csh -c "sapcontrol -nr 00 -function Stop"
Jun 20 16:23:05 host123 sapHanaControl.pl[15003]: 20.06.2018 16:23:05
Jun 20 16:23:05 host123 sapHanaControl.pl[15003]: Stop
Jun 20 16:23:05 host123 sapHanaControl.pl[15003]: FAIL: NIECONN_REFUSED (Connection refused), NiRawConnect failed in plugin_fopen()
Eu realmente apreciaria alguma ajuda se alguém aqui já tivesse encontrado o mesmo problema que nós. Espero que seja informação suficiente. Pode fornecer mais, se necessário.
Atualizar
Eu vejo os seguintes processos em execução quando o sistema está funcionando normalmente:
[root@wsstadt325 ~]# ps -ef | grep sapstartsrv
d61adm 1740 1 0 11:56 ? 00:00:01 /usr/sap/D61/HDB05/exe/sapstartsrv pf=/usr/sap/D61/SYS/profile/D61_HDB05_wsstadt325 -D -u d61adm
sapadm 1741 1 0 11:56 ? 00:00:04 /usr/sap/hostctrl/exe/sapstartsrv pf=/usr/sap/hostctrl/exe/host_profile -D
d21adm 1946 1 0 11:56 ? 00:00:02 /usr/sap/D21/ASCS01/exe/sapstartsrv pf=/usr/sap/D21/SYS/profile/D21_ASCS01_wsstadt325 -D -u d21adm
d21adm 2182 1 0 11:56 ? 00:00:02 /usr/sap/D21/D00/exe/sapstartsrv pf=/usr/sap/D21/SYS/profile/D21_D00_wsstadt325 -D -u d21adm'
Chnaged meu script para registrar a saída "ps -ef | grep sapstartsrv" quando o sistema for reinicializado / desligado.
ps -ef | grep sapstartsrv
sapadm 1683 1 0 13:52 ? 00:00:01 /usr/sap/hostctrl/exe/sapstartsrv pf=/usr/sap/hostctrl/exe/host_profile -D
root 5706 5522 0 14:00 ? 00:00:00 sh -c ps -ef | grep sapstartsrv
root 5708 5706 0 14:00 ? 00:00:00 grep sapstartsrv
O serviço sapstartsrv é iniciado por um serviço SAP padrão (sapinit) que obtém o startet antes do meu próprio Serviço Systemd (Então, em uma reinicialização, é a ordem inversa [Parar meu serviço Systemd - > interromper o serviço Sapinit]) parece ser que systemctl começa a matar a sessão do usuário (no meu caso para o usuário: d21adm e d61adm) onde o processo sapstartsrv está em execução antes que meu serviço Systemd real seja interrompido. (Espero que faça pelo menos um pouco de sentido)
Aqui está uma imagem de toda a cadeia de sistemas (meus serviços estão no final):
Os serviços envolvidos:
- sapinit.service (o padrão)
- saphana.service (meu costume)
