Solicitação de início de serviço repetida muito rapidamente, recusando-se a iniciar o limite

23

Eu tenho um serviço systemd que exibe o seguinte erro service start request repeated too quickly, refusing to start

Entendo que o serviço está configurado para reiniciar em caso de falha e está reiniciando novamente. Mas quando exatamente ele se recusa a reiniciar? Existe um limite ou número que o define?

Além disso, o que too quicklyexatamente significa, é um limite de número de reinicializações em um determinado período de tempo?

linux systemd

— Vikas Tiwari
fonte

26

O limite padrão é permitir 5 reinicializações em um período de 10 segundos. Se um serviço ultrapassar esse limite devido à Restart=opção de configuração na definição de serviço, ele não tentará reiniciar mais.

As taxas são configuradas com as opções StartLimitIntervalSec=e StartLimitBurst=, e a Restart=opção controla quando o SystemD tenta reiniciar um serviço.

Mais informações em man systemd.unite man systemd.service.

Em seguida, use systemctl daemon-reloadpara recarregar a configuração da unidade.

— Sven
fonte

3

Obrigado @Sven. Onde essas configurações são definidas?

— Vikas Tiwari

No arquivo de serviço. As StartLimit...opções podem não estar lá e basta usar o padrão (5 reinicia em 10 segundos).

— Sven

O valor padrão está escrito em algum outro arquivo de configuração?

— precisa saber é o seguinte

3

Os padrões podem ser configurados, por exemplo, /etc/systemd/system.confcom as DefaultStartLimitIntervalSecopções (e similares). No entanto, eles geralmente não são definidos e os padrões compilados são usados. Veja man systemd-system.

— Sven

@ Sven Onde está o arquivo de serviço?

— Utilizador

2

Vale ressaltar que algumas falhas parecem gerar esse erro, enquanto a causa é diferente.

Eu comentei o bantime padrão e inseri um inline alternativo **bantime = 7200 #3600**

Também adicionei uma nova seção [sasl] , que incluía um nome de filtro que foi alterado em relação ao fornecido no artigo que eu estava seguindo.

Em vez de errar em um desses, fail2ban se recusou a reiniciar, dando ao

solicitação de início do serviço repetida muito rapidamente, recusando-se a iniciar o erro

Somente quando eu comentei a seção [sasl], recebi um erro referente a um período de tempo inválido, do qual deduzi que ele não pode lidar com comentários embutidos.

Quando corrigi isso e descomentei a nova seção [sasl], recebi um erro que o filtro não foi encontrado. A substituição do filtro nomeado corretamente resultou no recarregamento fail2ban conforme o esperado.

Portanto, se você fizer alterações e receber esse erro, remova as alterações e ainda receba o mesmo erro antes de tentar corrigir um sintoma.

— MickG
fonte

0

Uma maneira rápida e suja que acabei de usar para esse mesmo problema é que criei um script de wrapper bash que dorme para que o serviço não seja iniciado tão rápido. Funciona para mim, pois não preciso reiniciar imediatamente.

/root/sleep_and_start_autossh.sh

    /bin/bash -e
    sleep 200
    /usr/bin/autossh args...

/etc/systemd/system/autossh.service

    StartLimitIntervalSec=120 # this didn't seem to do much for me.
    #ExecStart=/usr/bin/autossh args ...
    ExecStart=/root/sleep_and_start_autossh.sh

— deploycat
fonte

Você precisa abaixar StartLimitIntervalSec para evitar a aceleração ou configurá-lo como 0 para desativar. Leia a documentação do systemd.

— Vladimir Panteleev 22/09

0

Você não especifica qual serviço falha ao iniciar com este erro.

Eu tive esse problema e fail2ban, como na resposta do MickG , o erro estava na minha configuração fail2ban e não tinha nada a ver com a configuração do serviço systemd.

Com fail2ban, a solução é iniciá-lo com

fail2ban-client -x start

que exibirá uma mensagem de erro detalhada. Por alguma razão, ao usar systemctl start fail2bano erro real, ele se perde e não pode ser encontrado em nenhum registro.

Depois que o erro de configuração é corrigido, o serviço pode ser novamente parado ou (re) iniciado com systemd.

— mivk
fonte