日志文件未写入（乘客）
在本地，我的应用程序运行良好并写入其日志。
我的生产服务器运行 CentOS，并带有运行 Passenger 的 Apache 服务器。当尝试调试时，我注意到我的日志文件没有被写入。我做的第一件事是 chmod 0666 它们，当我发现这不起作用时，我查看了我的 apache 日志。我发现这个：Rails 错误：无法访问日志文件。请确保 /var/www/vhosts/mysite.com/rails/exp/releases/20091124020342/log/Production.log 存在并且 chmod 0666。日志级别已提升为 WARN 且输出定向到 STDERR，直到出现问题是固定的。
（注意：我正在使用 capistrano 进行部署）
无论如何，我在 Google 上搜索了一下，发现人们说这是一个 SELinux 问题，所以我查看了乘客的文档，发现了这个： http://www.modrails.com/documentation/Users%20guide.html#_my_rails_application_8217_s_log_file_is_not_being_writing_to
基本上说这样做： chcon -R -h - t httpd_sys_content_t /path/to/your/rails/app
但是，当我填写正确的路径时，我得到： 操作不受支持。
很困惑......有什么想法吗？
Locally, my app runs fine on and writes to its logs.
My production server is running CentOS with an Apache server running Passenger. When trying to debug, I noticed my log files were not being written to. First thing I did was chmod 0666 them, and when I found out that didn't work I looked at my apache log. I found this: Rails Error: Unable to access log file. Please ensure that /var/www/vhosts/mysite.com/rails/exp/releases/20091124020342/log/production.log exists and is chmod 0666. The log level has been raised to WARN and the output directed to STDERR until the problem is fixed.
(Note: I am deploying with capistrano)
Anyway, I Googled around and found people saying it's an SELinux issue, so I looked on passenger's docs and found this: http://www.modrails.com/documentation/Users%20guide.html#_my_rails_application_8217_s_log_file_is_not_being_written_to
which basically says do this: chcon -R -h -t httpd_sys_content_t /path/to/your/rails/app
However, when I fill in the proper path I get: Operation not supported.
Pretty stumped...any ideas?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
日志文件中“ls -l”的结果是什么？在 Ubuntu 上，我必须确保日志文件上的 acl 是正确的。我通常通过使用
Deploy 来解决乘客运行的用户。
What are the results of "ls -l" on your log file? On Ubuntu I have to make sure that the acl's are correct on the log files. I usually solve that by using
Deploy is the user that passenger runs in.
我的 ubuntu 10.x 服务器遇到了同样的问题。这是我在排除故障时学到的知识。
您可以通过top命令（或任何其他技术）查看进程以哪个用户身份运行。
无论哪种情况 - 我的恰好是后者 - 如果 Rails 进程无法写入日志文件，则日志中不会显示任何内容（废话）。 Rails 将忽略此权限被拒绝错误并尝试正常处理请求。
解决方案是确保 Rails ruby 进程以拥有 Rails 部署、config/environment.rb 文件以及日志目录和文件的同一用户身份运行。
这可以是部署配置步骤来 chown 有问题的文件和目录，也可以配置 apache 并告诉它以特定用户（例如 root 而不是无人）运行 ruby 进程。显然不建议以 root 身份运行，但如果您出于某种原因这样做，并且需要查看正确写入的 Rails 日志，则可以通过添加以下内容来完成此操作
：服务器），典型的情况应该是rails应用程序目录由该非root用户拥有，并且乘客应该以同一用户的身份运行rails进程。一切都应该正常进行。
[1] http://www.modrails.com/documentation/Users% 20guide%20Apache.html#_the_rails_application_reports_that_it_8217_s_unable_to_start_because_of_a_permission_error
I ran into the same issue with my ubuntu 10.x server. Here's what I learned while troubleshooting.
You can see which user the processes are run as via the top command (or any number of other techniques).
In either case -- mine happend to be the latter -- if the rails processes cannot write to the log files, nothing shows up in the logs (duh). Rails will ignore this permission denied error and try to process the requests as normally.
The solution is to ensure that the rails ruby processes are running as the same user that owns your rails deployment, config/environment.rb file and the logs directory and files.
This can be either deplyment configuration step to chown the files and directories in question or configuring apache and telling it to run the ruby process as a specific user (say, root instead of nobody). Running as root is obviously not recommended, but if you are doing that for whatever reasons, and need to see rails logs properly written to, you can do this by adding the following
If you are not deploying as root (which is the case on another server I have), the typical scenario should be that the rails app directory is owned by that non-root-user, and passenger should run the rails processes as that same user. And everything should just work.
[1] http://www.modrails.com/documentation/Users%20guide%20Apache.html#_the_rails_application_reports_that_it_8217_s_unable_to_start_because_of_a_permission_error