Log files not recorded (Passenger)

Question

Locally, my application works fine and writes its logs.

My production server runs CentOS with the Apache server running with Passenger. While trying to debug, I noticed that my log files were not being logged. The first thing I did was chmod 0666, and when I found out that this did not work, I looked at my apache log. I found this: Rails Error: Could not access the log file. Make sure that /var/www/vhosts/mysite.com/rails/exp/releases/20091124020342/log/production.log exists and is chmod 0666. The log level is raised to WARN and the output routed to STDERR until the problem is fixed.

(Note: I am deploying using capistrano)

Anyway, I googled around and found people saying this SELinux question, so I looked at the passenger documents and found this: http://www.modrails.com/documentation/Users%20guide.html#_my_rails_application_8217_s_log_file_is_not_being_written_toten

which basically talks about this: chcon -R -h -t httpd_sys_content_t / path / to / your / rails / app

However, when I fill in the correct path, I get: The operation is not supported.

Pretty dumb ... any ideas?

Answer 1

What are the results of "ls -l" in your log file? On Ubuntu, I have to make sure that acl is correct in the log files. I usually solve this using

sudo chown -R deploy:deploy /path/to/app 

Deployment is the user who runs the passenger.

Answer 2

I encountered the same problem with my ubuntu 10.x server. Here is what I found out during troubleshooting.

• As mentioned earlier in the docs, Passenger starts the batch processes as the owner of the config / environment.rb file. If you haven’t done something special, it’s usually the same as the owner of your entire rails application directory. In the case of deploying capistrano, this is the capistrano user.
• If the .rb environment is owned by root (most likely because you are deploying as root), the passenger starts the rails processes as "nobody"

You can see which user is executing the processes, using the top command (or any number of other methods).

In any case - my case will be the last - if the rail processes cannot be written to the log files, nothing is displayed in the logs (duh). Rails ignores this permission, which rejects the error, and tries to process requests as usual.

The solution is to ensure that the ruby ​​rail processes operate as the same user who owns the rail deployment, the config / environment.rb file and the log directory and files.

This can be either a definition configuration step to process the files and directories in question, or configure apache, and let it know that it starts the ruby ​​process as a specific user (say root instead). Obviously, working with root privileges is not recommended, but if you do this for any reason and you need to write rails logs correctly, you can do this by adding the following

 # in /etc/apache2/apache2.conf PassengerDefaultUser root 

If you do not use it as root (which takes place on another server that I have), the typical scenario should be that the rails application directory belongs to this user without root authority, and the passenger must run the rail processes, the same user. And everything should 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