startpar processo deixado pendurado ao iniciar processos de rc.local ou init.d

Question

Eu tenho um problema peculiar ao iniciar processos em andamento (semelhantes a serviços) a partir de um script init.d completo (estilo SysV) ou de uma chamada simples de uma linha do arquivo rc.local da seguinte forma:

su someuser -c "/home/someuser/watchdog.sh &"

Onde watchdog.sh contém isto:

#!/bin/bash

cd /home/someuser

until ./eventMonitoring.py
do
    echo "Program crashed with exit code $?. Starting again..." >&2
    sleep 1
done

Sempre tenho um processo adicional na lista de processos:

UID        PID  PPID  C    SZ   RSS PSR STIME TTY          TIME CMD
root      3048     1  0  1024   620   1 20:04 ?        00:00:00 startpar -f -- rc.local

Se eu iniciá-lo a partir do meu script init.d (fonte: link )

Eu recebo o mesmo processo, mas é startpar -f - userspaceServices

O que diabos é esse processo? Por que não há menção ao argumento -f ao olhar para a página man do startpar? O que estou fazendo errado em termos de iniciar um processo na inicialização como outro usuário, que este estranho processo startpar precisa ser deixado (ou iniciado) também? Por que esse processo não está presente em nenhum outro script init.d?

Alguém por favor pode me ajudar a esclarecer este assunto?

Nota: Meu sistema é o Debian Wheezy 7.4.0

UPDATE!
Abri uma nova questão no stackoverflow para discutir o comportamento startpar do ponto de vista de um programador: link

    

Answer 1

Minha investigação sobre isso me levou a uma solução. Então agora eu sei como fazer isso corretamente, mas eu ainda não entendi porque startpar se comportou como aconteceu. Então, se alguém está disposto a intervir e explicar isso, estou mais do que disposto a aceitar essa resposta do que esta.

Basicamente, o problema é que eu chamei os scripts sem redirecionar (ou fechar) entrada padrão, saída padrão e erro padrão para um arquivo ou para / dev / null e, por algum motivo, startpar ( "usado para executar vários scripts de nível de execução em paralelo" processo, que para mim é o que inicia outros processos durante a inicialização, foi bloqueado neste meu script por causa disso. Ele lançou meu script, mas ele próprio não terminou de ser executado e foi deixado no estágio mostrado na lista de processos como:

UID        PID  PPID  C    SZ   RSS PSR STIME TTY          TIME CMD
root      3048     1  0  1024   620   1 20:04 ?        00:00:00 startpar -f -- rc.local

O código-fonte de startpar está aqui: link

Folheei e fiz minha análise inicial em uma nova pergunta que publiquei no stackoverflow. Encontre o link na UPDATE que adicionei à minha pergunta aqui.

A solução final que usei é esta:

su someuser -c "nohup some_script.sh >/dev/null 2>&1 &"

su - substitua a identidade do usuário pelo argumento someuser
-c - su para executar o comando especificado
nohup - Execute um comando imune a restrições. Para evitar casos em que o processo pai terminará o processo filho. Adicionado aqui apenas no caso. Mas na verdade não tem efeito no meu caso particular. Se é necessário depende do ambiente (verifique shopt )
> / dev / null - Reduza a saída padrão para nada, basicamente desabilitando-a.
< strong> 2 > & 1 - Redirecionar erro padrão (2) saída para a saída padrão (1), que é redirecionada para null
& - desanexar para o plano de fundo. redireciona a entrada padrão também para / dev / null.

Olhando os descritores de arquivo de outros daemons conhecidos em execução no meu sistema, vejo que o redirecionamento para / dev / null é uma coisa comum. E apenas alguns processos daemon na verdade fecharam stdin, stdout, stderr. O que poderia ser alcançado por exemplo:

su someuser -c "some_script.sh 0<&- 1>&- 2>&- &" 

Em um sentido prático, é tudo a mesma coisa e é necessário (qualquer opção) separar de maneira limpa um processo como um daemon em segundo plano.