capistrano-plugins / capistrano-unicorn-nginx

Capistrano tasks for automatic and sensible unicorn + nginx configuration
MIT License
175 stars 81 forks source link

Change nginx log file dirs #24

Closed bruno- closed 10 years ago

bruno- commented 10 years ago

nginx_access_log_file and nginx_error_log_file are currently located in the shared_path. This is great when deploying to a single node, but when web node is no_release we have to explicitly create the dir for the log files.

I propose the following change:

Benefits:

bruno- commented 10 years ago

Btw. this does not make it into the new gem release

rhomeister commented 10 years ago

I agree. Keeping the nginx logs in the default location is a better solution than the one we have now. When using one nginx for multiple apps, currently each app is "competing" to have the nginx logs in its shared/log. After every cap setup, the log directory is moved to the release directory of the current app. (BTW your suggestion corresponds to my current setup for many projects: I don't change nginx's logging directory, because nginx is the front end for multiple apps.)

However, I'm not entirely convinced about creating the symlink into the shared_path/log. The reason is related to the use of logrotate for splitting up and compressing log files, and deleting old ones. When using logrotate, and when nginx logs are in their default location, the Ruby related logs in shared_path/log would be rotated there, while the nginx access and error log would be rotated in /var/log/nginx.

The slight inconsistency that would result from using the symlink as you suggest, is that you only get a single reference to the current nginx access and error logs, while the shared/log is populated with all the rotated Ruby logs. Therefore, if I want to look at nginx log history, I still have to go to the default location.

My suggestion: let's completely return to the default. Leave the nginx logs in their default location, and don't make symlinks from shared/log.

bruno- commented 10 years ago

It's good to have the perspective from other tools - I agree with that argument.