como trabalhar em torno de "estado FATAL inserido, muitas tentativas de início muito rápido" no supervisor

3

Estou apenas testando meu supervisor com a configuração simples do programa:

[program:test]
command=python -c "print 'hello'"
autostart=true                
autorestart=true
exitcodes=1
user=ratdon
stdout_logfile=/opt/log/test.log
stderr_logfile=/opt/log/test.log

Iniciando meu supervisord como sudo supervisord -n -c /opt/supervisord.conf & . Mas depois de algumas desovas, ele pára de gerá-lo novamente.

2016-02-01 11:17:58,973 CRIT Supervisor running as root (no user in config file)
2016-02-01 11:17:58,973 WARN Included extra file "/opt/test.ini" during parsing
2016-02-01 11:17:58,994 INFO RPC interface 'supervisor' initialized
2016-02-01 11:17:58,994 CRIT Server 'inet_http_server' running without any HTTP authentication checking
2016-02-01 11:17:58,995 INFO supervisord started with pid 19644
2016-02-01 11:17:59,998 INFO spawned: 'test' with pid 19648
2016-02-01 11:18:00,026 INFO exited: test (exit status 0; not expected)
2016-02-01 11:18:01,030 INFO spawned: 'test' with pid 19650
2016-02-01 11:18:01,064 INFO exited: test (exit status 0; not expected)
2016-02-01 11:18:03,072 INFO spawned: 'test' with pid 19653
2016-02-01 11:18:03,104 INFO exited: test (exit status 0; not expected)
2016-02-01 11:18:06,108 INFO spawned: 'test' with pid 19657
2016-02-01 11:18:06,138 INFO exited: test (exit status 0; not expected)
2016-02-01 11:18:07,139 INFO gave up: test entered FATAL state, too many start retries too quickly

Eu quero que o supervisor continue a reiniciar o programa até que eu pare o supervisord.

É possível? Se sim como fazer isso?

Existe alguma opção para fazer o supervisor registrar o stdout com o registro de data e hora ou precisamos colocar o registro de data e hora em stdout em si?

    
por RatDon 01.02.2016 / 07:04

2 respostas

0

Encontrei o mesmo caso de uso enquanto trabalhava em um ambiente de serviços de micro do Docker. No meu caso, havia a possibilidade de que o Nginx começasse antes que sua configuração gerada dinamicamente estivesse em vigor.

No momento não há como permitir que o Supervisord reinicie o serviço infinitamente até que o processo tenha iniciado com sucesso.

No entanto, existe uma solução viável usando a opção startretries . Com a opção startretries , o Supervisord irá reiniciar o número de vezes dado ou até que o processo tenha iniciado com sucesso.

No meu caso de uso específico, o período de tempo para a condição de corrida foi menor que um segundo, então definir startretries=2 foi suficiente. No entanto, você pode configurá-lo para um valor muito maior, se necessário.

[program:test]
startretries=10
    
por 07.06.2016 / 10:23
0

Na verdade, uma maneira melhor é atribuir prioridade ao programa iniciado

[program:x]
priority=1
[program:y]
priority=2    

observe que números mais baixos indicam uma ordem de inicialização mais alta e, claro, incluindo um grande número de novas tentativas

    
por 21.11.2016 / 15:54