Início / unix / Perguntas / 410603
Accepted
Arkaik
Asked: 2017-12-14 03:06:25 +0800 CST

Código de retorno do serviço systemd de manipulação de script

  • 772

Estou escrevendo um serviço systemd que pode ser iniciado ou interrompido usando comandos systemctl.

No entanto, este programa também pode retornar com vários códigos de retorno e eu gostaria de lidar com esses códigos de retorno.

Por exemplo, se o serviço foi interrompido systemctl stop <service>, não deve fazer nada. Mas se não foi morto por systemctl e retornado por si só, quero executar um pós-script no qual eu possa obter o código de retorno e executar ações dependendo de seu valor.

Modificado após a resposta @NarūnasK
Ao ter a versão systemd >= v232, tudo bem com a resposta @NarūnasK

No entanto, ao não ter a boa versão do systemd, como isso poderia ser feito?

Eu pensei em fazer algo como

ExecStart=/bin/sh -c '<service> -C /etc/<service_conf_file>; [ $? -eq 1 ] && { <action> }'
linux systemd

1 respostas

  1. Best Answer

    ExecStopPost= deve fazer o que você deseja.

    Comandos adicionais que são executados depois que o serviço é interrompido. Isso inclui casos em que os comandos configurados em ExecStop= foram usados, em que o serviço não possui nenhum ExecStop= definido ou em que o serviço foi encerrado inesperadamente. Esse argumento usa várias linhas de comando, seguindo o mesmo esquema descrito para ExecStart=. O uso dessas configurações é opcional. A substituição do especificador e da variável de ambiente é suportada. Observe que – ao contrário de ExecStop= – os comandos especificados com essa configuração são invocados quando um serviço falha ao iniciar corretamente e é desligado novamente.

    Recomenda-se usar esta configuração para operações de limpeza que devem ser executadas mesmo quando o serviço falhou ao iniciar corretamente. Os comandos configurados com esta configuração precisam ser capazes de operar mesmo que o serviço tenha falhado na inicialização no meio do caminho e deixado dados inicializados incompletos ao redor. Como os processos do serviço já foram encerrados quando os comandos especificados com esta configuração são executados, eles não devem tentar se comunicar com eles.

    Observe que todos os comandos configurados com esta configuração são chamados com o código de resultado do serviço, bem como o código de saída e o status do processo principal, definidos nas variáveis ​​de ambiente $SERVICE_RESULT, $EXIT_CODE e $EXIT_STATUS, consulte systemd.exec (5) para detalhes.

    Em seu script, você pode ler $EXIT_CODEou $EXIT_STATUSvariáveis ​​de ambiente e tomar as medidas apropriadas.

    EDITAR

    Você pode usar a seguinte solução alternativa com systemd < 232.

    amostra_script :

    #! /bin/bash --

sleep 5

## Non standard exit code
exit 255

    exit_handler :

    #! /bin/bash --

CODE="${1:-N/A}"

echo CODE: $CODE
echo SERVICE_RESULT: $SERVICE_RESULT
echo EXIT_CODE: $EXIT_CODE
echo EXIT_STATUS: $EXIT_STATUS

    sample_script.service :

    # systemctl cat sample_script.service 
# /etc/systemd/system/sample_script.service
[Unit]
Description=My service
After=network.target rsyslog.service

[Service]
Type=simple
Restart=never
ExecStart=/bin/bash -c '/tmp/sample_script || /tmp/exit_handler $?'
ExecStopPost=/tmp/exit_handler

[Install]
WantedBy=multi-user.target

    Status do sample_script.service :

    # systemctl status sample_script.service 
● sample_script.service - My service
   Loaded: loaded (/etc/systemd/system/sample_script.service; enabled)
   Active: inactive (dead) since Thu 2017-12-14 12:29:16 GMT; 7s ago
  Process: 16511 ExecStopPost=/tmp/exit_handler (code=exited, status=0/SUCCESS)
  Process: 16505 ExecStart=/bin/bash -c /tmp/sample_script || /tmp/exit_handler $? (code=exited, status=0/SUCCESS)
 Main PID: 16505 (code=exited, status=0/SUCCESS)

Dec 14 12:29:11 build-local systemd[1]: Started My service.
Dec 14 12:29:16 build-local bash[16505]: CODE: 255
Dec 14 12:29:16 build-local bash[16505]: SERVICE_RESULT:
Dec 14 12:29:16 build-local bash[16505]: EXIT_CODE:
Dec 14 12:29:16 build-local bash[16505]: EXIT_STATUS:
Dec 14 12:29:16 build-local exit_handler[16511]: CODE: N/A
Dec 14 12:29:16 build-local exit_handler[16511]: SERVICE_RESULT:
Dec 14 12:29:16 build-local exit_handler[16511]: EXIT_CODE:
Dec 14 12:29:16 build-local exit_handler[16511]: EXIT_STATUS:

    Você pode ver que exit_handlerfoi chamado duas vezes. A princípio de bashonde tem o código de saída fornecido a ele e depois como ExecStopPost=script, onde o argumento posicional do código de saída não foi fornecido, portanto, imprimiu N/A.

    • 2

relate perguntas