upstart 系统自带，无需安装，节省资源，稳定

Rails App Server 进程不需要监视，不会挂，另外 Uncorn Puma 之类的 Master 进程本身有进程保护的。

monit 另外，systemd 和监视有啥关系？

#3 楼 @vkill 姑且也是有一些监视功能的吧，比如崩溃自动重启什么的

用 Foreman 导出配置，系统是 upstart 的时候导出 upstart，是 systemd 的时候导出 systemd。

http://chloerei.com/2014/12/15/foreman/

我倾向于选择系统自带的进程管理器，upstart 或者 systemd，优点：

• 没有第三方依赖
• 由 init 进程负责开机自动启动，并将进程的生命周期托管给 init 统一管理
• 被管理进程自己无需实现 daemonize，且也不需要 PID 文件（我一直觉得 PID 记录进程号的管理方式带来的问题比解决的问题更多）
• 被管理进程自己无需实现日志文件管理，只需要把日志信息输出到 STDOUT，然后就可以通过 syslog 统一管理，如果是 systemd 的话，还可以用更先进的 journald 来统一管理日志

缺点正如 @rei 的文章中提到的 Foreman 导出 upstart 配置后的遇到的问题一样。

• 如果将进程托管给 upstart，通过 Capistrano / Mina 执行 upstart 的管理命令的话。Capistrano 建议配置 sudo 执行特定命令时不要求密码，虽然 ok，但是我觉得这是权宜之计
• 如果将进程托管给 upstart，但是由 Capistrano / Mina 来控制的话，则需要通过 PID 文件记录进程号，方便查找进程以及向进程发送信号
• 如果不将进程托管给 upstart，而是通过 Capistrano / Mina 来管理的话，那就只用到了 upstart 做开机自动启动，也要让 upstart 以用户身份执行进程启动脚本，以及在启动前初始化好 Shell 环境变量（如 rvm/rbenv, RAILS_ENV 等），这样失去了 upstart 对进程的托管和 monitor 的作用，需要通过第三方如 monit 来解决进程意外挂掉的情况。

总之这部分坑很多，没有标准答案，需要根据自己对系统的理解以及项目的需要灵活搭配调整。

一直用的是 CentOS puma 交给自身的 master 管理，没问题。内存占用过大了，直接 kill 了 worker 就重启了。 后台跑的 sleep 的 rake 任务用 god，最大的问题是 stop 的时候停不掉。目前是手工关掉 god 然后再 kill 掉进程。 supervised 搞不定 rvm 环境初始化，放弃了。monit 没搞明白，预感会遇到 rvm 环境问题，放弃，用 god 了。

核心服务都用默认的或者不用（如上面说的本身自带进程保护），小脚本程序用了 eye（类似 god，用下来感觉更简单好用耗资源）。

@nine https://github.com/seuros/capistrano-puma/blob/master/lib/capistrano/templates/puma_monit.conf.erb#L6 不会有 rvm 的问题

#9 楼 @vkill 3x