Precisa de ajuda para converter scripts de serviço init.d em systemd (CentOS)

3

Eu passei vários dias em um assunto que é incrivelmente frustrante e estou sem opções.

Atualmente estou usando um servidor do CentOS 6.8 em funcionamento para o nosso site. O CentOS 6 (Enterprise Linux 6 ou EL6) usa o modelo init.d mais antigo para scripts de inicialização. Existe um programa que meu chefe exige que eu use, o SonicWALL CDP Agent. Ele tem um servidor de backup SonicWALL e seu software "agente" é executado em segundo plano para fazer backup de arquivos e pastas específicos no servidor. Na verdade, é construído sobre o Acronis TrueImage, mas isso é outra história.

O maior problema é que o agente CDP usa o Adobe AIR. Eles devem ter projetado dessa forma para serem multiplataformas (já que eles têm um instalador para Windows / OSX / Linux), mas é claro que a Adobe parou completamente de suportar o AIR no Linux de 64 bits há algum tempo. O site deles dá alguns passos para instalá-lo, mas isso remonta ao Red Hat 5.5, nem mesmo 6.

Consegui que o AIR fosse instalado no EL7 seguindo as etapas do EL6 e apenas observando onde os nomes dos pacotes foram alterados nos repositórios. Interessante notar que o instalador normal da GUI (AdobeAIRInstaller.bin) não funciona e dá algum erro sobre "talvez o seu administrador proíba as instalações" mesmo quando executado como root), mas os arquivos .rpm funcionam.

Eu tenho os mais atuais:
adobeair-core-2.6.0-19170.noarch.rpm
adobeair-2.6.0-19170.i686.rpm

Combinado com as bibliotecas GTK2 i686, isso realmente funciona.

No entanto, o agente CDP é mais complicado que isso. Existem dois serviços do sistema que precisam ser executados para que o software do agente funcione de fato (e, se pensarmos sobre isso, isso será necessário para que os backups automáticos funcionem de qualquer maneira).

Seu instalador, no entanto, tem anos e coloca os scripts de inicialização no init.d. Isso é "suposto" para trabalhar no EL7, mas isso não acontece. Passei horas mexendo com isso e simplesmente não funciona.

Então, basicamente, existem dois binários que precisam ser executados. Os comandos para iniciá-los são:

/sbin/cdp/cdpagentproxy  
/sbin/cdp/cdpdaemon start  

Se eu abrir um terminal e executá-lo manualmente, eles funcionarão - e eu posso abrir o CDP Agent e ele funcionará. No entanto, eles não estão iniciando na inicialização devido à incompatibilidade init.d / systemd.

Então eu fiz alguns "serviços" simples e os coloquei nos lugares certos. O arquivo cdpdaemon.service, por exemplo:

[Unit]
Description=CDP Daemon Service
After=syslog.target network.target

[Service]
Type=forking
ExecStart=/sbin/cdp/cdpdaemon start

[Install]
WantedBy=multi-user.target

Coloquei isso em /usr/lib/systemd/system/cdpdaemon.service e fiz um link simbólico para ele em /etc/systemd/system/multi-user.target.wants/cdpdaemon.service .

Mas eis o que acontece quando tento verificar o status:

[root@localhost Desktop]# systemctl status cdpdaemon.service
● cdpdaemon.service - CDP Daemon Service
   Loaded: loaded (/usr/lib/systemd/system/cdpdaemon.service; enabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Sun 2016-08-21 22:08:13 EDT; 10s ago
      Process: 1596 ExecStart=/sbin/cdp/cdpdaemon start (code=exited, status=0/SUCCESS)
 Main PID: 1633 (code=exited, status=127)

Aug 21 22:08:13 localhost.localdomain systemd[1]: Starting CDP Daemon Service...
Aug 21 22:08:13 localhost.localdomain cdpdaemon[1596]: Starting  process.
Aug 21 22:08:13 localhost.localdomain systemd[1]: Started CDP Daemon Service.
Aug 21 22:08:13 localhost.localdomain systemd[1]: cdpdaemon.service: main process exited, code=exited, status=127/n/a
Aug 21 22:08:13 localhost.localdomain systemd[1]: Unit cdpdaemon.service entered failed state.
Aug 21 22:08:13 localhost.localdomain systemd[1]: cdpdaemon.service failed.

O outro faz a mesma coisa. Parece que ele tenta ser executado, mas depois para e relata um erro. Se eu abrir um terminal e simplesmente digitar /sbin/cdp/cdpdaemon start , ele funcionará perfeitamente bem.

Estou fazendo algo errado aqui? Eu não entendo os diferentes tipos de opções de "destino" nem o "depois" e tipo. (Eu basicamente peguei um serviço de trabalho, copiei o texto e mudei o comando)

Suponho que outra opção seria fazer um cronjob que seja executado em um determinado momento (digamos, 11h, se os backups forem executados à meia-noite) que executam os dois comandos, mas isso parece ser o caminho errado para fazer isso. / p>

O programa é executado, mas não consigo executá-lo sozinho sem que eu inicie os dois processos auxiliares.

Edit: Eu pensei em fornecer o arquivo install.sh caso isso ajude. Você pode ver onde ele verifica qual distro você está executando e cria os scripts init.d.

link

    
por Danny Forche 22.08.2016 / 05:01

3 respostas

0

"Tipo = fokring" é para serviços que bifurcam um filho e colocam isso em segundo plano e saem normalmente. Olhando para a sua saída, parece que seus programas não fazem isso. o que acontece se você alterar "Type = forking" para "Type = simple"?

    
por 22.08.2016 / 21:09
0

Primeiro, determine se esses processos não se baseiam ou não. Se você iniciar um processo de "bifurcação" em um terminal, ele libera o terminal e "entra em segundo plano". Tais processos precisam de Type=forking . Caso contrário, se um processo não liberar o terminal, a menos que você o termine com Ctrl + C ou coloque & no final da linha de comando, ele será Type=simple . É simples assim.

Em segundo lugar, você mencionou que há dois processos que precisam ser iniciados em ordem. Você escreveu os arquivos da unidade para os dois? Se não, faça agora mesmo.

Em terceiro lugar, não esqueça as dependências. Se o último processo ( /sbin/cdp/cdpdaemon start ) depender do primeiro ( /sbin/cdp/cdpagentproxy ), você precisará expressar o requisito e ordenar dependências entre eles nos arquivos da unidade.

Se, por exemplo, os arquivos de unidade criados por você forem denominados cdpagentproxy.service e cdpdaemon.service , respectivamente, será necessário colocar essas linhas no arquivo cdpdaemon.service unit:

[Unit]
Requires=cdpagentproxy.service
After=cdpagentproxy.service

(Coloque essas linhas dentro da seção [Unit] existente, é claro. Eu incluí o cabeçalho da seção apenas para completar.)

Em seguida, execute systemctl daemon-reload , mate os dois processos e tente iniciar a unidade manualmente ou simplesmente adicione-a para iniciar automaticamente e reinicializar.

    
por 23.08.2016 / 22:01
0

Vamos recuar um segundo.

O processo sonicwall não é compatível com o RHEL / Centos7.

Pare aí. Passe para o bom pessoal da Sonicwall para sua correção; isso é exatamente o que você deve pagar a eles taxas de licença, e eles (devem) ter o conhecimento necessário para suportar seu software desse jeito.

O CentOS6 está em suporte por mais meia década, mas eles devem começar uma transição eeeeeasy.

    
por 14.06.2018 / 07:02