Ubuntu 20.04虚拟机中Rails 5.2的Puma workers无法启动求助

以下是几个针对性的排查方向，对应你遇到的「服务启动有输出但无pid/state文件、worker未启动」问题：

• 环境变量不完整
  SysVinit脚本运行时不会自动加载部署用户的shell环境（比如rbenv路径、RAILS_ENV变量），而你手动在current目录执行时依赖的是当前shell的环境，所以能正常运行。
  解决：在/etc/init.d/puma_myarticles_staging脚本开头补充环境变量配置：

  export PATH="$HOME/.rbenv/bin:$PATH"
  eval "$(rbenv init -)"
  export RAILS_ENV=staging
  

  同时用su - deploy -c "你的启动命令"切换到部署用户身份执行，避免环境差异。

• 权限与路径配置错误
  一是SysVinit默认以root身份运行，而应用目录属于部署用户，导致Puma无法写入pid/state文件；二是pid/state路径如果指向current目录（软链接），重启时可能失效。
  解决：

  1. 检查shared/tmp/pids、shared/tmp/sockets目录权限，确保部署用户拥有读写权限；
  2. 在puma.rb里明确将pid和state路径指向共享目录：

     pidfile "/home/deploy/myarticles/shared/tmp/pids/puma.pid"
     state_path "/home/deploy/myarticles/shared/tmp/pids/puma.state"
     

• 启动命令参数缺失
  手动执行rails s用的是默认WEBrick服务器，而Puma需要明确的启动参数才能后台运行并生成pid/state文件。
  检查init脚本里的启动命令是否符合规范：

  rbenv exec bundle exec puma -C /home/deploy/myarticles/shared/config/puma.rb -e staging -d
  

  重点确认：有没有加-d参数让Puma后台运行，配置文件路径是否指向shared目录下的puma.rb，是否指定了正确的RAILS_ENV。

• 通过日志定位具体错误
  直接查看Puma的错误日志是最有效的排查方式，比如实时监控shared/log/puma.stderr.log：

  tail -f /home/deploy/myarticles/shared/log/puma.stderr.log
  

  启动服务后，日志会输出具体失败原因——比如找不到bundle命令、配置文件语法错误、端口被占用等。

内容的提问来源于stack exchange，提问作者Asif