背景

我们在使用 cli 工具时，经常有这样的需求： ① 失败自动重启 ② 后台守护进程运行

在守护进程这件事上，我们常用的有这些工具：

• systemd
• init
• supervisior
• pm2
• tmux、screen
• nohup

以上工具都或多或少存在一些问题，以下逐个分析一下

各工具优劣

systemd & init

systemd 和 init 都是在 linux 体系下的进程管理方式，优点是，只要在 linux 下，这就是一定会存在的能力，因此兼容性很好。缺点是，一方面只有在 linux 下有，家用 pc 上无法使用；需要单独写配置文件。

这两种方式是 linux 下最常用的方案，操作系统级别的支持还是很可靠的，重启策略、日志 等都直接可用。兼容性最好。

之前在 如何解决linux下的代理访问 也有用到 systemd

参考文档
官方文档
systemd man 翻译
一个案例

supervisor

这是一个类似 systemd 的 python 程序，只要有 python 环境则都可以运行。优点是，只要有 python 环境，则可以运行。缺点是，需要单独安装、写配置文件、需要设置supervisor自启动

配置文件可以参考 官方文档
另外，社区有一个 golang 版本的实现 ，最大的价值在于无需依赖，在 docker 中或者在一些轻量级的系统中挺适用。

在容器时代之前，这是一个被广泛用作业务进程管理的工具。

supervisor 和 systemd 的一个比较： 参考资料

pm2

毋庸置疑，这是一个神器。强大到令人发指(主要是操作太友好了)。
优点：好用，强大
缺点：nodejs 依赖

pm2 可以直接让提供网络服务的 nodejs 程序拥有多进程能力，之前在 nodejs多进程管理的方式 有提到

ps: 多一嘴，如果 pm2 的面板是开源的就更香了
使用参考官方文档

tmux | screen | nohup

这几个算是一类工具，都是把 在前台执行的程序 放到后台运行。

nohup 是最简单的，使用时，直接使用 nohup xxxx & 或者把日志定向到特定文件 nohup xxx > xx.log， nohup 的缺点在于无法恢复到交互状态，往往只能通过 kill 进程号来结束运行。

tmux 和 screen 这类，弥补了 nohup 不能恢复到交互状态的缺点.

• 新增一个运行的命令 screen -S xxsessname xxx
• 使用 ctl + a + d 从当前 screen 出去
• 使用 ctl + a + c 在当前 screen 分一个子 screen 出来 (等同在当前terminal 下输入 screen 命令)
• 使用 ctl + a + a 在同一个 screen 的不同子 screen 切换
• 使用 screen -list 查看有哪些 screen 在运行
• 使用 screen -r xxxsessname 恢复到一个 screen 中

tmux 类似。

这几个工具，都是 session 级别的，没有 开机拉起、失败重启 的策略，当处理一些耗时的命令时可用，例如 gzip、wget 等

golang做到简单的daemon

用 service 项目

这个项目 比较有意思，这是把 golang 的程序结合着各个平台的 daemon 工具来使用，相当于它来帮你写 systemd 的 service 文件(linux下)。

直接用代码实现

• 封装实现一个直接在后台运行的 golang 程序

---

People may doubt what you say, but they will believe what you do.
— Lewis Cass