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

13

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 a falha e está sendo reiniciado novamente. Mas quando exatamente se recusa a reiniciar? Existe um limite ou número que o define?

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

    
por Vikas Tiwari 20.04.2017 / 11:47

3 respostas

12

O limite padrão é permitir 5 reinicializações em um período de 10 segundos. Se um serviço exceder esse limite devido à opção Restart= config 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 opção Restart= controla quando o SystemD tenta reiniciar um serviço.

Mais informações em man systemd.unit e man systemd.service .

    
por 20.04.2017 / 11:58
1

Vale a pena notar que algumas falhas parecem causar esse erro, enquanto a causa é diferente.

Comentei o bantime padrão e inseri uma alternativa inline **bantime = 7200 #3600**

Eu também adicionei uma nova seção [sasl] , que incluía um nome de filtro que havia mudado do nome dado no artigo que eu estava seguindo.

Em vez de cometer erros em um desses, o fail2ban recusou-se a reiniciar, fornecendo o

service start request repeated too quickly, refusing to start error

Somente quando eu comentei a seção [sasl], recebi um erro que se referia a um bantime inválido, do qual eu concluí que ele não pode lidar com comentários in-line.

Quando corrigi e descomentei a nova seção [sasl], recebi um erro informando que o filtro não foi encontrado. A substituição pelo filtro com o nome correto resultou no fail2ban como esperado.

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

    
por 03.07.2018 / 13:35
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 das reinicializações imediatas.

/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
    
por 22.04.2018 / 19:18

Tags