O systemd possui uma configuração de tempo limite diferente ao reinicializar versus o reinício normal de um serviço?

Question

O systemd usa uma configuração de tempo limite diferente para parar um daemon em execução (por exemplo, rsyslog ) ao reinicializar o sistema (por exemplo, executando reboot ) quando você simplesmente reinicia o daemon (por exemplo, systemctl restart rsyslog )?

Eu verifiquei a página systemd.service , mas não o fiz localize. Em vez disso, encontrei apenas as opções TimeoutStopSec e TimeoutStartSec . Eu configurei a opção TimeoutStopSec , mas parece que o systemd pode ser matando o daemon antes ele tem a chance de salvar seu estado com segurança e terminar corretamente .

EDIT 1:

Como @sourcejedi sugeriu (obrigado), devo enfatizar que esta não é uma instalação desktop onde o rsyslog está rodando, mas uma instalação do servidor Ubuntu 16.04 do rsyslog que recebe mensagens dos nós clientes e ainda pode conter muitas mensagens na memória quando pediu para terminar por systemd.

Eu tentei ajudar a solucionar alguns problemas de fila de disco corrompida aumentando o valor da opção TimeoutStopSec de 90 para 240 segundos, mas ainda observei essa mensagem várias vezes no arquivo de log relacionado:

rsyslogd: queue 'strm 0x26b4800', file '/var/spool/rsyslog/q_ForwardToNode2.00000003' opened for non-append write, but already contains 983505 bytes  [v8.29.0 try http://www.rsyslog.com/e/0 ]

A ideia era que o sistema poderia ser impaciente e estava matando o rsyslog enquanto ainda salvava o conteúdo no disco.

Eu tentei contornar um outro problema, forçando o systemd a esperar em uma conexão de rede ativa antes de tentar iniciar o rsyslog. Eu incluí o conteúdo de ambos os systemd Drop-Ins que estou usando abaixo para referência no caso de adicionar contexto útil para esta entrada.

cat /etc/systemd/system/rsyslog.service.d/*.conf | grep -Ev '#|^$'

Tentativa de contornar o github # 1656

[Unit]
Documentation=https://internal/wiki/url/here
After=network.target
Wants=nework.target

Tentativa de contornar o github # 1704

[Unit]
Documentation=https://internal/wiki/url/here
[Service]
TimeoutStopSec=240

Obrigado por ler isto.

    

Answer 1

Does issuing a reboot command result in systemd ignoring the TimeoutStopSec value?

Não. Isso seria horrível, e não é o que acontece.

EDIT: Algumas versões do systemd acima da v233 adicionam JobTimeoutSec=30min a reboot.target . Então, neste caso, haveria um limite superior (após o qual a unidade força uma reinicialização), mas é várias vezes maior do que os valores que você definiu até agora.

EDIT: Re "a idéia era que o sistema pode ser impaciente e estava matando o rsyslog enquanto ainda estava salvando conteúdo no disco", a mensagem parece ter sido um bug no rsyslog.

queue bugfix: file write error message was incorrect #1759 #1759

when a queue was restarted from disk file, it almost always emitted a message claiming "file opened for non-append write, but already contains xxx bytes" This message was wrong and did not indicate a real error condition. The predicate check was incorrect.

Observando os arquivos de serviço no Debian 9, observe que syslog.socket (fornecido pelo systemd) tem DefaultDependencies=no , mas também Before=shutdown.target e Conflicts=shutdown.target . A última linha é comentada Don't allow logging until the very end . Se você não tivesse esses dois últimos AND rsyslog.service tinha DefaultDependencies=no , o daemon syslog poderia ser re -ativado imediatamente e ser morto por systemd-shutdown.service ( systemd-shutdown ). systemd-shutdown usa o tempo limite padrão interno entre SIGTERM e SIGKILL, que eu acho que são 90 segundos.