Após atualizar para Jessie, o controle de serviço não retorna o resultado

Question

Na verdade não é debian, mas Raspbian Wheezy para Raspbian Jessie. Eu atualizo usando alguns comandos encontrados no fórum oficial do Raspbian.

cat / etc / debian_version = 8.0.

O problema é que não consigo ver nenhum resultado quando reinicio o serviço.

Antes da atualização (Wheezy):

# service tor restart
[ok] cccc
[ok] ddd
# _

Após a atualização (Jessie):

# service tor restart
# _

E todos os resultados são gravados em / var / log / syslog ... Como posso reverter isso? Eu quero ver o resultado real, não escrito para log.

    

Answer 1

service agora é tratado pelo systemd, e o systemd é silencioso quando tudo corre bem. Não parece haver uma maneira de mudar isso. Lennart adicionou um item TODO para adicionar um comportamento de restauração de modo detalhado semelhante ao que você depois, mas três anos mais tarde ainda é na lista TODO !

Você sempre pode definir uma função de shell para fazer algo como

service tor restart && echo '[OK]' || echo '[Failed]'

(com tor substituído por $1 e qualquer mensagem que você queira nos comandos echo ), mas isso não lhe dará detalhes de unidades executando múltiplos comandos.

systemctl status tor

mostrará o status detalhado da unidade relevante, portanto, outra opção poderia ser acoplar isso com start ou restart .

    

Answer 2

A lot of services on error, some services always return sucess, even if the service not started, because systemd is starting a kind of service manager instead of the service itself..... And no dont trust service status about what hapenned I get a lot of times a "STARTED OK" and service is really not running without any feedback! So it still does not solve the problem! But is better if you run journal -xe lot better than doing this, but not good enough because you need to run it everytime and remember of it. – @Luciano Andress Martini

"Nenhum resultado" significa que a operação foi bem-sucedida. Este é o padrão do UNIX. É como os comandos cp ou rm se comportam, por exemplo.

Se o seu serviço estiver escrito incorretamente, ele poderá retornar o sucesso e, em seguida, falhar imediatamente depois. quando lê uma configuração ruim. Este é um bug no serviço! Se um script sysvinit se comporta assim, você teria exatamente o mesmo problema! Não há nada que o systemd possa fazer para corrigir isso.

Quando sua unidade falha, há um truque para visualizar as últimas 10 linhas apenas do seu daemon. Execute systemctl status como o usuário raiz (por exemplo, sudo ). Como alternativa, você pode adicionar seu usuário como membro de um dos grupos systemd-journal ou adm .

Quando preciso de mais do que as últimas 10 linhas, uso journalctl -u tor -b , ou seja, tudo desde a inicialização atual. Ou se você tiver reiniciado muitas vezes durante a inicialização atual, talvez queira usar journalctl -u tor --since=-1hour . Ou, resumindo, --since=-1h .

Acho que systemctl já sugere que você execute systemctl status quando a unidade não iniciar. (Infelizmente, o systemctl nunca menciona o problema das permissões).

systemctl também sugere journalctl -xe . Pessoalmente, acho que isso é inútil. -x apenas acrescenta muito barulho. -e ignora, por exemplo mensagens stdout / stderr e qualquer outra coisa que não esteja explicitamente marcada como uma mensagem de erro. (Ele até ignora as mensagens stderr, desculpe. Mudar isso é estranho: permitiria que linhas stderr fossem reordenadas v.s. stdout, o que pode ser indesejável para scripts de shell).

Existe uma queixa de usuário semelhante no rastreador de problemas do systemd , que envolve alguns outros serviços com bugs. (Ou, um deles parece que pode estar deliberadamente falhando "em segundo plano", depois de um longo tempo limite de rede. Novamente, é exatamente assim que o serviço está escrito, não está tentando incomodar você).