Tengo un servicio systemd que muestra el siguiente error service start request repeated too quickly, refusing to start
Entiendo que el servicio está configurado para reiniciarse en caso de falla y se reinicia una y otra vez. Pero, ¿cuándo exactamente se niega a reiniciar? ¿Hay un límite o número que lo define?
Además, ¿ too quicklyqué significa exactamente, es un límite de número de reinicios en un período de tiempo determinado?
Respuestas:
El límite predeterminado es permitir 5 reinicios en un período de 10 segundos. Si un servicio supera ese umbral debido a la Restart=opción de configuración en la definición del servicio, no intentará reiniciarse más.
Las tarifas están configurados con los StartLimitIntervalSec=y las StartLimitBurst=opciones y los Restart=controles de opción cuando SystemD intenta reiniciar un servicio.
Más información en man systemd.unity man systemd.service.
Luego, use systemctl daemon-reloadpara recargar la configuración de la unidad.
StartLimit...posible que las opciones no estén allí y solo usen el valor predeterminado (5 reinicios en 10 segundos).
/etc/systemd/system.confcon las DefaultStartLimitIntervalSecopciones (y similares). Sin embargo, a menudo no se establecen y se utilizan los valores predeterminados compilados. Ver man systemd-system.
Vale la pena señalar que algunas fallas parecen arrojar este error, mientras que la causa es diferente.
Comenté el tiempo de espera predeterminado e inserté una línea alternativa
**bantime = 7200 #3600**
También agregué una nueva sección [sasl] , que incluía un nombre de filtro que había cambiado del que figuraba en el artículo que seguía.
En lugar de error en cualquiera de esos, fail2ban se negó a reiniciar, dando el
la solicitud de inicio del servicio se repite demasiado rápido, negándose a iniciar el error
Solo cuando comenté la sección [sasl], recibí un error que se refería a un tiempo de espera inválido, del cual deduje que no puede hacer frente a los comentarios en línea.
Cuando arreglé eso y descomenté la nueva sección [sasl], recibí un error de que no se encontró el filtro. La sustitución del filtro con el nombre correcto dio como resultado la recarga de fail2ban como se esperaba.
Entonces, si realiza cambios y obtiene este error, asegúrese de eliminar los cambios y aún obtener el mismo error antes de intentar solucionar un síntoma.
Una forma rápida y sucia que acabo de usar para este mismo problema es que creé un script de bash wrapper que duerme para que el servicio no se inicie tan rápido. Funciona para mí ya que no necesito los reinicios inmediatos.
/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
StartLimitIntervalSec para evitar la aceleración, o establecerlo en 0 para deshabilitar. Lea la documentación del sistema.
No especifica qué servicio no puede comenzar con este error.
Tuve este problema y fail2ban, como en la respuesta de MickG , el error estaba realmente en mi configuración de fail2ban y no tenía nada que ver con la configuración del servicio systemd.
Con fail2ban, la solución es comenzar con
fail2ban-client -x start
que mostrará un mensaje de error detallado. Por alguna razón, al usar systemctl start fail2banel error real se pierde y no se puede encontrar en ningún registro.
Una vez que se corrige el error de configuración, el servicio puede volver a detenerse o (re) iniciarse con systemd.