当Puma作为守护进程运行时(即使用-d
标志(,Puma似乎不会登录到stdout_redirect
指定的位置。
以前有人见过这种行为吗?如果有,找到了为彪马生成正确日志文件的解决方法(特别是在stdout_redirect
到位的情况下,特别是针对RubyonRails应用程序(?
stdout_redirect
不工作的原因是运行rails server -d
时config/puma.rb
从未运行过。您可以通过更改端口号甚至在文件中引入语法错误来亲自演示这一点。
彪马作为机架服务器运行,因此由机架中间件启动。Rack代码只是使用核心RubyProcess
类来分离进程:
def daemonize_app
Process.daemon
end
不幸的是,Process.daemon
默认做两件事:
- 将当前工作目录更改为root('/'(
- 将stdout和stderr重定向到
/dev/null
因此,当Puma服务器初始化时,所有进程输出都被装箱,并且由于/config/puma.rb
不存在,Puma会返回到其硬编码的默认设置。
如果你临时破解rack
代码来覆盖chdir行为,你实际上可以展示你想要的行为:
def daemonize_app
Process.daemon(true)
end
如果.daemon
的第一个参数是true
,则不会更改当前工作目录,因此config/puma.rb
将运行。
除了对Rack进行某种丑陋的猴子补丁外,一个(可能也是丑陋的(解决方法是跳过-d
选项,在config/puma.rb
中滚动自己的补丁。例如:
# ... rest of the puma config
return unless ENV['DAEMONIZE_PUMA'].present?
puts 'Running puma as a daemon...'
Process.daemon(true)
然后:
% export DAEMONIZE_PUMA=true
% rails server
=> Booting Puma
=> Rails 6.1.4 application starting in development
=> Run `bin/rails server --help` for more startup options
Running puma as a daemon...
% tail log/puma.out
=== puma startup: 2021-07-17 10:03:37 +1200 ===