Bug：对于无法启动的错误应该直接退出

[shigma]

目前的想法是 @koishijs/cli 中添加一个 --no-deamon 模式，然后根据进程间通信来判断是否启用。

Koishi 子进程启动完成后会发送一个 ready 事件给父进程，如果在此之前退出则不进行重启。

[ilharp]

--no-deamon 是指包 @koishijs/cli 不开启 daemon 功能吗？我认为 @koishijs/cli 的守护功能仍然是有必要的。在此之前，可以先简述一下 @koishijs/cli 守护的工作方式吗？

另，在之前的讨论中提出使用 ExitCode 的方式判断应当重启还是报错退出，现在为何又提出了新的守护方式？该方式有何优点？

[shigma]

@koishijs/cli 的守护模式如下：

• 主进程
  1. 主进程解析启动指令，将部分参数写入环境变量后 fork 子进程。
  2. 当接收到 start 事件时，记录启动状态和 autoRestart 的值；如果此时 buffer 不为空含有消息则向子进行发送 buffer 中的消息。
  3. 当接收到 queue 事件时，将 payload 记录到 buffer 中（queue 事件来源于子线程的重启和关闭指令，将会发送 queue 事件后分别以 51 和 0 为 exit code 结束进程）。
  4. 当子进程退出时，如果尚未启动完成，或者 exit code 为 0, 130, 137 中的一个，或者（exit code 不等于 51 并且 autoRestart 为假）时按子进程的 exit code 退出；否则重启子进程。
• 子进程
  1. 子进程定位并解析配置文件。
  2. 子进程创建应用实例。
  3. 子进程依次加载插件。
  4. 子进程启动应用。
  5. 应用启动完成后向主进程发送 start 事件，伴随 autoRestart 配置项。
  6. 开始监听 SIGINT 和 SIGTERM。
• code 说明
  • 0：手动退出
  • 51：重启（magic code）
  • 130：SIGINT
  • 137：SIGKILL
  • 其他的 code 均视为未知异常。

[shigma]

我认为只需要有一套守护系统即可。

--no-deamon 的意思是，子进程依旧使用 config 中提供的配置启用 deamon 功能，但是并没有父进程了。父进程将由 koi 担任，完成与 @koishijs/cli 父进程相同的职责。

[shigma]

保留以 exit code 为判断标准的方式，但是对于启动完成前的退出特殊处理。这是因为启动完成前尚未接触到任何外界消息，此时的退出必然是可重现的，没有必要重启。

[ilharp]

我认为只需要有一套守护系统即可。

--no-deamon 的意思是，子进程依旧使用 config 中提供的配置启用 deamon 功能，但是并没有父进程了。父进程将由 koi 担任，完成与 @koishijs/cli 父进程相同的职责。

按照此方案，Koi 和 Koishi 中将会存在两份语言不同但逻辑相同的守护代码？我认为这是不合理的。

---

保留以 exit code 为判断标准的方式，但是对于启动完成前的退出特殊处理。这是因为启动完成前尚未接触到任何外界消息，此时的退出必然是可重现的，没有必要重启。

这是不正确的。我又进行了一次思考，然后我认为「可重现」的判定标准似乎相对灵活。考虑以下场景：

1. 端口被占用。此时的退出 仅当端口仍然被占用时可重现。考虑某系统启动时先启动占用该端口的服务 A，后启动 Koi。而服务 A 可能占用端口几秒后就关闭了，此时的 Koi 不能重启显然是不正确的，相信你也同意。

2. 配置文件有误。此时的退出 仅当配置仍然有误时可重现。但此时我们有以下考虑：「用户有能力修正配置，那么他必然有能力手动重启 Koi」，因此我们将其作为「退出而不重启」的典型场景。实际上该情况也并非必然可重现。

[shigma]

按照此方案，Koi 和 Koishi 中将会存在两份语言不同但逻辑相同的守护代码？我认为这是不合理的。

你现在的方案也是存在两份语言不同但部分逻辑相同的守护代码。我认为要么统一交给 CLI 要么就反过来。

[ilharp]

统一交由 @koishijs/cli 实现。

实现： 05b68241e656190d02efbe05dcc80147378217a9