【发布时间】：2014-11-03 00:41:10
【问题描述】：
【问题讨论】：
【发布时间】：2014-11-03 00:41:10
【问题描述】：
他们关注的不是守护进程本身，而是管理该进程并确保其正常运行。他们引用了围绕守护进程构建的 kludgey 框架的实例，其中守护进程的编写并未考虑到管理，因此需要过多的资源来重新启动它、清理它等等。
他们指出并推荐使用系统管理工具软件，包括smf（Solaris）、upstart（Linux）、launchd（OSX），甚至是老旧的init和ttys（较旧的 Unix 版本和基于 BSD 的发行版）。他们没有提到systemd（也是Linux），但这可能是时机。他们也没有提及inetd 或xinetd，它们也使基于网络的守护进程的管理和重启变得简单易行。
所以他们并不是真的建议不要守护进程；他们建议您在发明了漂亮的守护程序服务流程之后，不要围绕它重新发明管理框架。开发您的服务器时要了解它的管理方式，这可能会大大减少所涉及的总工作量。按照目前的说法，这是一种devops 的态度。
【讨论】：
我将添加到主管列表中，immortal 一个 *nix 跨平台（与操作系统无关）主管，它简化了 12 因素实践。
时间戳
默认情况下，日志中的选项时间戳设置为 false，这有利于遵循 12 因素的应用程序，并且在日志为“JSON”结构的情况下，可以轻松解析。
【讨论】：
基本上目的是从容器中移除服务管理逻辑并将其作为基础架构的一部分
考虑服务崩溃的场景 - 基础设施可能决定在不同的服务器上重新启动它，而不是重新启动映像中的服务，这在服务器加载或发生故障的情况下可能无济于事
【讨论】：