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ê).