FATAL Exited too quickly (process log may have details)的解决方案
作为一个混混的开发，不会啥容器操作。所以一般都是用supervisor来管理一些运行的进程
用了一段时间还是比较好用的，这个软件也是用的Python开发。
但在使用的过程中，status时会出现
FATAL Exited too quickly (process log may have details)
BACKOFF Exited too quickly (process log may have details)
这样的提示，表示该进程已经退出，明明设置了autorestart=true了，为什么还是退出了。
以下内容参考supervisor的官方网站信息：http://supervisord.org/configuration.html
autorestart
Specifies if supervisord should automatically restart a process if it exits when it is in the RUNNING state. May be one of false, unexpected, or true. If false, the process will not be autorestarted. If unexpected, the process will be restarted when the program exits with an exit code that is not one of the exit codes associated with this process’ configuration (see exitcodes). If true, the process will be unconditionally restarted when it exits, without regard to its exit code.
Note
autorestart controls whether supervisord will autorestart a program if it exits after it has successfully started up (the process is in the RUNNING state).
supervisord has a different restart mechanism for when the process is starting up (the process is in the STARTING state). Retries during process startup are controlled by startsecs and startretries.
Default: unexpected
Required: No.
Introduced: 3.0
上面标红的是比较重要的一句话,自动重启只能在监控的进程在RUNNING的状态下才有效
那说了，被supervisor托管的检查在supervisor定义的状态中除了RUNNING还有另外的状态
官网找了一下，找不到相关的信息，那手动在supervisorctl中查看，一般的状态还有FATAL,BACKOFF,STARTING,STOPED。
中断插入一些信息，刚刚仔细看了一下官方文档，还是上面这段话，红字下面这段话也非常重要
在每个任务的配置文档里面有startsecs与startretries
再次中断插入一张官方来的好图
自信看看官方的文档，结合这个图，就可以很好的理解supervisor的管理逻辑
一个重点是autorestart,与startretries和startsecs的关系非常有意思
首先是autorestart,当你的进行超过startretries设置的时间后，进程的状态将由STRATING切换到RUNNING状态
autorestart的作用只能在RUNNING状态下才会起作用，如果你将autorestart设置为true,假如你设置的startretries少于你程序的运行时间，
也就是说你的程序可以进入RUNNING状态，那恭喜你，你这个程序将永远不会终止，他将一直由supervisor托管，Foreve，当然手动命令拆散不算。
所以从autorestart的角度，就有了解决方案
首先从图中就可以看到出现FATAL的情况，是因为出现了多次BACKOFF之后，才会进入FATAL状态。
那为什么会进入BACKOFF状态，那就需要聊一下startretries与startsecs了[如果没有设置的情况，参数默认为3和1]。
在启动进程的命令之后，在小于startsecs的时间，进程的状态为STARTING状态，当这个时候，进程出现问题, 退出
那就进入到了BACKOFF状态，也就用到了startretries参数了。只要连续的在STARTING状态下重启次数小于startretries
supervisor就会再次重新拉起该任务，
Retries will take increasingly more time depending on the number of subsequent attempts made, adding one second each time.
So if you set startretries=3, supervisord will wait one, two and then three seconds between each restart attempt, for a total of 5 seconds.
上面的文字表示了，在STARTING状态，出现重新拉起任务会自动添加休眠间隔时间，在休眠间隔时间的状态就是BACKOFF了
在BACKOFF的状态下，要么继续拉起来，要么就FATAL了。
啰嗦的讲的这么多，现在知道了BACKOFF的原因，也知道了为什么会FATAL了。
解决方案
因为你的进程未进入RUNNING，重启次数多了，然后就FATAL，那如何让进程能够进入RUNNING呢
第一个方法就是调整startsecs的参数，默认为1，一对于计算机来说，那可以做的事情太多了，那设置为0，岂不是一启动就进入RUNNING了，只要进入了该状态
autorestart的参数就用上了效果，这个对于时间要求比较高的进程还是比较好用的
2022-10-13 03:51:13,584 INFO spawned: 'test_supervisor' with pid 6963 2022-10-13 03:51:13,601 INFO success: test_supervisor entered RUNNING state, process has stayed up for > than 0 seconds (startsecs) 2022-10-13 03:51:13,603 INFO exited: test_supervisor (exit status 0; expected) 2022-10-13 03:51:13,846 INFO spawned: 'test_supervisor' with pid 6964 2022-10-13 03:51:13,865 INFO success: test_supervisor entered RUNNING state, process has stayed up for > than 0 seconds (startsecs) 2022-10-13 03:51:13,867 INFO exited: test_supervisor (exit status 0; expected) 2022-10-13 03:51:13,886 INFO spawned: 'test_supervisor' with pid 6965 2022-10-13 03:51:13,911 INFO success: test_supervisor entered RUNNING state, process has stayed up for > than 0 seconds (startsecs) 2022-10-13 03:51:13,914 INFO exited: test_supervisor (exit status 0; expected)
这是一秒钟的重启进程状况，我那云主机一秒启动了3次
第二种方案就是将自己的项目启动的时候加入阻塞时间,假如默认为1的状况下，主函数进入的时候，先sleep大于1的时间，这段时间肯定不会报错
所以肯定能够进入RUNNING状态，那就又能够愉快的使用autorestart了。
上面两种方案都是定频率的重启
第三种
下次就进入通过startretries来重启进程吧，这个时候autorestart的设置是无效的.
这个用在只执行一次，也就是跑通一遍的情况比较好.
首先将autorestart设置为false,或者unexpected，将startretries略小于完整执行跑完整个进程的大概时间.
将startretries设置为合适的参数，这样在STARTING阶段会通过startretries来重启
注意，这个重启的时间会自增
差不多就写到这里，花了大半天时间写下来，实际的使用中，大家应该结合实际的情况，调整到合适自己的参数
