Rails 6.0.3搭配Nginx、Puma时production.log实时跟踪无更新问题

结合你当前的Nginx + Puma部署架构、文件状态（production.log仅733字节、最后修改时间停留在4月25日）、生产配置内容，可按以下优先级定位解决：

高频原因与对应解决方式 #

• 日志轮转导致的文件句柄偏移
  这是生产环境最常触发同类问题的原因：如果服务器配置了logrotate日志自动轮转，流程将原production.log重命名为带日期后缀的归档文件、同时新建同名空文件时，没有通知Puma服务重新打开日志文件，Puma进程仍然持有旧文件的inode句柄持续写入——你tail跟踪的是新建的空文件，自然永远看不到新增内容，和文件写入权限无关。
  排查命令：lsof -p $(pgrep -f "puma.*master") | grep production.log，如果返回的关联文件是带日期后缀的归档文件，即可确认该问题。
  解决操作：执行kill -USR1 $(pgrep -f "puma.*master")向Puma主进程发送重开日志的信号，发送完成后即可正常看到原路径production.log的更新。后续修改logrotate配置，在轮转完成的脚本段加上相同的信号发送命令，避免后续复现。

• 日志被重定向到标准输出，未写入本地文件
  Rails 6 支持通过RAILS_LOG_TO_STDOUT环境变量控制日志输出路径，开启该变量后Rails会直接把日志输出到标准输出而非本地文件，这种场景下本地production.log从应用启动后就不会有任何写入，日志会被systemd等进程管理器收集到系统运行日志中。
  排查命令：cat /proc/$(pgrep -f "puma.*master")/environ | tr '\0' '\n' | grep RAILS_LOG_TO_STDOUT，如果返回值为true即可确认问题。
  解决操作：

• 如果需要保留本地日志写入，移除该环境变量后重启Puma服务即可

• 如果要保留标准输出的日志模式，直接跟踪对应系统日志即可（比如systemd托管的服务可执行journalctl -u [你的Puma服务名称] -f）
  另外需要同步检查Puma自身配置文件puma.rb里的stdout_redirect配置，确认是否将Puma本身及Rails输出的所有日志重定向到了其他路径，而非项目目录下的log文件。

• 运行环境参数不匹配
  如果Puma启动时没有指定正确的RAILS_ENV参数，实际运行的是development/test环境，日志会写入对应环境的日志文件（如development.log），production.log自然不会有更新。
  排查命令：cat /proc/$(pgrep -f "puma.*master")/environ | tr '\0' '\n' | grep RAILS_ENV，确认返回值是否为production，如果不是则需要在Puma的启动配置（如systemd的service文件）中补上Environment=RAILS_ENV=production参数，重启服务即可。

• 磁盘空间耗尽导致写入静默失败
  磁盘空间打满后，即便文件权限正常，应用进程也会因为没有可用写入空间静默丢弃日志，不会抛出报错，表现为文件大小长期不增长。
  排查命令：df -h检查log目录所在分区的占用率，如果达到100%，清理磁盘空间后重启Puma即可恢复日志写入。

补充：你当前配置里的config.log_level = :debug已经是最低日志级别，不会因为日志级别过高过滤掉请求日志，无需调整这部分配置。

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