Início / unix / Perguntas / 784380
Accepted
User051209
Asked: 2024-10-02 18:23:49 +0800 CST

Definir StandardOutput=null no arquivo de serviço que inicia um script é equivalente ao redirecionamento da saída padrão do script para /dev/null?

  • 772

Meu serviço atual e script de shell

Eu tenho um arquivo de serviço systemd chamado myservice.service. O serviço é iniciado na inicialização. O serviço inicia o script de shell /usr/bin/myscript.shcomo você pode ver abaixo na seção [Service]:

...
[Service]
Type=forking
ExecStart=/usr/bin/myscript.sh
PIDFile=/dev/shm/myscript.pid
...

O conteúdo do script é:

#!/bin/sh
/usr/bin/script-python.py > /dev/null &
echo $! > /dev/shm/myscript.pid

O script shell myscript.shinicia o script Python: script-python.py. Pelo redirecionamento, > /dev/nulla saída padrão de script-python.pyé enviada para /dev/nulle, portanto, é perdida.

Alterações para usar Service->StandardOutput=null

Na documentação do systemd do StandardOutput li a seguinte frase:

null conecta a saída padrão a /dev/null, ou seja, tudo escrito nele será perdido.

Então estou pensando em executar as seguintes alterações nos meus arquivos:

  1. myservice.servicetorna-se (adicionar StandardOutput=null):
...
[Service]
Type=forking
ExecStart=/usr/bin/myscript.sh
PIDFile=/dev/shm/myscript.pid
StandardOutput=null
...
  1. myscript.shtorna-se (remover >/dev/null):
#!/bin/sh
/usr/bin/script-python.py &
echo $! > /dev/shm/myscript.pid

Minha pergunta

Minha pergunta é: se eu fizer as modificações mostradas acima o resultado é exatamente o mesmo da minha situação atual: todas as saídas de script-python.pysão perdidas? Não há nenhuma diferença?

shell-script

1 respostas

  1. Best Answer

    Esses dois são quase equivalentes:

    [Service]
ExecStart=/bin/sh -c '/usr/bin/script-python.py >/dev/null'

    e

    [Service]
ExecStart=/bin/sh -c '/usr/bin/script-python.py'
StandardOutput=null

    O primeiro redirecionará stdoutdo .pyscript para /dev/null. O segundo redirecionará do script stdoutinteiro para . Neste caso, eles são equivalentes, mas se seu script contivesse outras linhas, elas não seriam silenciadas (apenas ).sh/dev/nullshscript-python.py

    Como mencionei nos comentários, seu script parece ter sido escrito para o antigo sistema SysV init. Ele funcionará bem com systemdwith Type=forking, mas ele explicitamente faz coisas que systemdteriam sido feitas para você automaticamente.

    Se eu estivesse integrando isso em uma das minhas máquinas, eu excluiria /usr/bin/myscript.she usaria este arquivo de serviço:

    [Service]
ExecStart=/usr/bin/script-python.py
StandardOutput=null

    Você pode ver que isso é muito mais simples.

    Desde que script-python.pynão faça spam de stdout, eu provavelmente também apagaria a StandardOutput=linha e deixaria journaldque ele cuidasse disso. Às vezes, vejo pessoas usando >/dev/nullporque executam manualmente o script de um terminal e querem reutilizar esse terminal para outras coisas sem serem incomodadas pelo stdout. Isso não é uma preocupação quando é um serviço.

    Aqui está uma explicação de cada linha alterada:

    • ExecStart=/usr/bin/script-python.py: O Systemd pode executar o script python diretamente. Isso não era possível no SysV init. Isso evita invocar sh. desnecessariamente.
    • excluído Type=forking : O shscript que você tinha originalmente, bifurcaria ( &), permitindo script-python.pya execução em segundo plano. É assim que os serviços costumavam funcionar. Como estamos executando script-python.pydiretamente, não precisamos disso. O padrão Type=simplefaz com que o systemd monitore script-python.pydiretamente.
    • excluído PIDFile= : Isso é usado apenas com Type=forking. É uma maneira de ajudar systemda saber qual processo bifurcado ele deve rastrear como o processo primário. systemdfaz um bom palpite onde há apenas um processo filho, então ele provavelmente poderia ter sido excluído de qualquer maneira.

    Algumas outras notas:

    • Seu PIDFile=está em /dev/shm/. Este é um lugar estranho para colocá-lo porque esse dispositivo geralmente é gerenciado por chamadas de memória compartilhada. /run/script-python.pidseria mais apropriado se você decidir manter isso.

    • Os scripts init do sysV salvariam o PID em um arquivo para que ele pudesse ser recuperado mais tarde para parar/reiniciar. Com systemdo gerenciamento do seu serviço, isso é desnecessário, porque o PID é rastreado internamente, e os sinais de eliminação são definidos por outras opções.

      #!/bin/sh
case $1 in
  start)
    /bin/foo &                # notice the fork.  foo will continue after sh finishes
    echo $! > /run/foo.pid    # Write the PID to a file for later recall
    ;;
  stop)
    pid=$(cat /run/foo.pid)   # Recall the PID
    /bin/kill $pid            # Use that PID to kill the process
    ;;
esac

    Então os usuários podem iniciar/parar o script com

    /etc/init.d/foo.sh start
/etc/init.d/foo.sh stop

    Isso foi substituído por

    systemctl start foo
systemctl stop foo
    • 2

relate perguntas