O script qstnhdr ___ init.d não fornece saída padrão ______ qstntxt ___

Estou usando o Debian Jessie e quando estou tentando usar algum script do init.d (iniciar, parar, reiniciar). Existem funções %code% %code% %code% que devem dar algo na saída padrão, mas isso não acontece. Na versão mais antiga do Debian eu lembro que funciona normalmente. Mesmo se estiver tentando usar um script com falha, ele sempre obterá a mesma saída:

%bl0ck_qu0te%     
______ azszpr250997 ___
%bl0ck_qu0te%

Não execute scripts em %code% diretamente.

Em sistemas operacionais systemd, não há garantia de que esses scripts existam, e muito menos que eles estejam especificando seu serviço. Mesmo no Debian 7, havia unidades systemd suplantando o System 5 %code% scripts; e isto é mais no Debian 8. Os comandos corretos para usar são:

  • %code% com seus subcomandos %code% , %code% , %code% , %code% e %code%
  • %code%
  • %code% e %code% , mas apenas se você for um script do mantenedor de pacotes

Isso é exatamente o que está acontecendo com você. Sua invocação direta do script está sendo substituída, através de um gancho dentro de uma biblioteca Debian amplamente utilizada de funções de script, com uma invocação de (neste caso particular)

%pre%

Você pode até ver isso na saída à sua frente. É o que o %code% significa. E claramente, longe de falhar, é sucesso em dizer ao systemd para reiniciar o serviço.

Os sinos e assobios interativos dentro do script %code% , incluindo mensagens coloridas, não são mais eficazes. Seu serviço não é executado como um processo filho de %code% . Ele é executado como um processo filho de %code% e possui conexão zero com o terminal no qual você está executando comandos interativamente.

Todo esse %code% scaffolding e geração de mensagens de log é totalmente desnecessário com o systemd, de qualquer forma. O systemd fornece mecanismos de serviço cruzado para habilitar e desabilitar serviços e para reiniciá-los automaticamente. Registra quando inicia e interrompe serviços, sem necessidade dos serviços para fazer isso. Pela minha conta, esse script %code% é simplesmente substituível por 16 unidades %code% comuns, uma para cada serviço. Veja como ficaria:

%pre%

Ligue para %code% , execute %code% e…

  • … há informações de status disponíveis com %code% .
  • … você o habilita para executar no bootstrap com %code% .
  • … você pode ver as entradas de log do systemd para iniciar e pará-lo com %code% .

É muito fácil para os outros 15.

Leitura adicional

___

Navegue suas respostas
0

Estou usando o Debian Jessie e quando estou tentando usar algum script do init.d (iniciar, parar, reiniciar). Existem funções log_failure_msg log_daemon_msg log_end_msg que devem dar algo na saída padrão, mas isso não acontece. Na versão mais antiga do Debian eu lembro que funciona normalmente. Mesmo se estiver tentando usar um script com falha, ele sempre obterá a mesma saída:

kuban@lenovo-y510p:/etc/init.d$ sudo /etc/init.d/parstart restart

[ ok ] Restarting parstart (via systemctl): parstart.service.

    
por Patryk 22.12.2015 / 18:54

1 resposta

1

I'm trying to use some script from init.d […]

Não execute scripts em /etc/init.d/ diretamente.

Em sistemas operacionais systemd, não há garantia de que esses scripts existam, e muito menos que eles estejam especificando seu serviço. Mesmo no Debian 7, havia unidades systemd suplantando o System 5 rc scripts; e isto é mais no Debian 8. Os comandos corretos para usar são:

  • systemctl com seus subcomandos status , start , stop , enable e disable
  • service
  • update-rc.d e invoke-rc.d , mas apenas se você for um script do mantenedor de pacotes

Isso é exatamente o que está acontecendo com você. Sua invocação direta do script está sendo substituída, através de um gancho dentro de uma biblioteca Debian amplamente utilizada de funções de script, com uma invocação de (neste caso particular) 

systemctl restart parstart.service

Você pode até ver isso na saída à sua frente. É o que o (via systemctl): parstart.service significa. E claramente, longe de falhar, é sucesso em dizer ao systemd para reiniciar o serviço.

Os sinos e assobios interativos dentro do script rc , incluindo mensagens coloridas, não são mais eficazes. Seu serviço não é executado como um processo filho de systemctl . Ele é executado como um processo filho de systemd e possui conexão zero com o terminal no qual você está executando comandos interativamente.

Todo esse /etc/szarp/parstart.cfg scaffolding e geração de mensagens de log é totalmente desnecessário com o systemd, de qualquer forma. O systemd fornece mecanismos de serviço cruzado para habilitar e desabilitar serviços e para reiniciá-los automaticamente. Registra quando inicia e interrompe serviços, sem necessidade dos serviços para fazer isso. Pela minha conta, esse script rc é simplesmente substituível por 16 unidades .service comuns, uma para cada serviço. Veja como ficaria: 

[Unit]
Description=The SZARP pserver-lite server
After=network.target 

[Service]
Type=simple
ExecStart=/usr/local/bin/pserver-lite --no-daemon

[Install]
WantedBy=multi-user.target

Ligue para /usr/local/etc/systemd/system/pserver-lite.service , execute systemctl daemon-reload e…

  • … há informações de status disponíveis com systemctl status pserver-lite.service .
  • … você o habilita para executar no bootstrap com systemctl enable pserver-lite.service .
  • … você pode ver as entradas de log do systemd para iniciar e pará-lo com journalctl .

É muito fácil para os outros 15.

Leitura adicional

por 22.12.2015 / 20:56

Tags

Atualizando o Java no CentOS Script com variável no caminho