Rails应用日志轮转后新日志属root而非apps用户的技术咨询

你的问题核心在于：Rails通过Passenger以apps用户运行，但日志轮转生成的新文件却归属root。这大概率是进程运行身份、目录权限或是否混用系统logrotate工具导致的，下面分情况给出解决方案：

先确认核心前提：Rails进程的运行用户 #

首先得确保Passenger真的在以apps用户运行你的Rails进程，否则后续配置都无效。你可以用这条命令检查：

ps aux | grep rails

看输出里的用户列，如果不是apps，需要先修正Passenger配置：在你的Nginx站点配置中添加passenger_user apps;，然后重启服务：

sudo systemctl restart nginx
passenger-config restart-app /path/to/your/rails/app

情况1：仅使用Rails自带的Logger轮转（你的当前配置） #

Ruby标准库的Logger由Rails进程创建和管理，正常情况下新日志文件的属主应该和进程用户一致（即apps）。如果出现root属主，可能是以下原因：

日志目录/初始日志文件权限问题 #

如果log目录或初始的production.log是root用户创建的，可能会导致轮转时出现权限继承异常。你可以先修复目录和文件的属主：

# 递归修改log目录下所有文件的属主为apps
sudo chown -R apps:apps /path/to/your/rails/app/log
# 设置目录权限为755，确保apps用户能读写
sudo chmod 755 /path/to/your/rails/app/log

之后手动删除当前日志文件，重启Passenger让Rails重新创建日志，再触发轮转（比如往日志中写入大量内容），检查新文件属主是否正常。

额外：显式指定日志文件权限 #

你还可以在production.rb中配置Logger时，明确指定文件权限，避免后续出现权限问题：

config.logger = Logger.new(
  config.paths["log"].first,
  3,
  10.megabytes,
  mode: 0664  # 确保apps用户拥有读写权限
)

情况2：混用了系统logrotate工具 #

如果你的服务器上还配置了系统logrotate（比如/etc/logrotate.d/下有针对你应用的配置），由于logrotate默认以root用户运行，切割后的文件自然会归属root。这种情况下，你需要修改logrotate配置，让它以apps用户身份执行：

编辑对应的logrotate配置文件（比如/etc/logrotate.d/your-rails-app），添加su apps apps行：

/path/to/your/rails/app/log/production.log {
  daily
  rotate 7
  missingok
  notifempty
  compress
  delaycompress
  su apps apps  # 指定用apps用户执行切割，新文件属主即为apps
}

先测试配置是否正确：

sudo logrotate -d /etc/logrotate.d/your-rails-app

如果没有报错，手动执行一次切割验证效果：

sudo logrotate -f /etc/logrotate.d/your-rails-app

最后验证 #

完成上述步骤后，重启Passenger，然后触发一次日志轮转（比如写满10M日志，或手动修改日志文件大小模拟），检查新生成的日志文件属主：

ls -l /path/to/your/rails/app/log/

如果显示apps apps就说明问题解决了。

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