Início / server / Perguntas / 845471
Accepted
Vikas Tiwari
Asked: 2017-04-21 01:47:10 +0800 CST

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

  • 772

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

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

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

linux

6 respostas

  1. Best Answer

    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 e e a StartLimitIntervalSec=opção controla quando o SystemD tenta reiniciar um serviço.StartLimitBurst=Restart=

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

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

    • 68

  2. Não é exatamente a mesma pergunta, mas como essa é a que aparece na pesquisa ...

    Se você quiser apenas iniciá-lo ignorando esse absurdo absurdo de limite (por exemplo, no Debian, onde é o resultado inevitável de serviços de inicialização automática do apt antes de serem configurados, condenando-os a falhar e fazer um loop e atingir o limite, enviando spam ao log com tanta força com o início erros de limite que você nem consegue ler facilmente a causa):

    Veja https://bugzilla.redhat.com/show_bug.cgi?id=1016548 onde Michal Schmidt diz que você pode encontrá-lo man systemd.servicee sugere redefinir o status de falha:

    systemctl reset-failed <service name>

    Então agora seu serviço pode começar. Ou pelo menos a causa atual do motivo pelo qual não deve estar no log, por exemplo. visto comjournalctl -x

    • 20

  3. Vale a pena notar que algumas falhas parecem lançar 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 havia sido alterado em relação ao fornecido no artigo que estava seguindo.

    Em vez de errar em qualquer um deles, o fail2ban se recusou a reiniciar, dando a

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

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

    Quando consertei isso e descomentei a nova seção [sasl], recebi um erro de que o filtro não foi encontrado. A substituição do filtro nomeado corretamente resultou no recarregamento do fail2ban conforme o 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.

    • 3

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

    Eu tive esse problema com fail2ban, e como na resposta de 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 algum motivo, ao usar systemctl start fail2bano erro real se perde e não pode ser encontrado em nenhum log.

    Uma vez corrigido o erro de configuração, o serviço pode ser novamente interrompido ou (re)iniciado com o systemd.

    • 1

  5. No meu caso, a mensagem de erro foi um pouco enganosa. O motivo da falha resultou de uma cópia entre máquinas. A linha

    User=my_user

    no meu arquivo de configuração de serviço /etc/systemd/system/infinite_script.servicefoi o culpado.

    A nova máquina não conhecia este usuário. Mudando para User=rootresolver este problema.

    • 1

  6. 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
    • 0

relate perguntas