Closed bruno- closed 10 years ago
Btw. this does not make it into the new gem release
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
.
It's good to have the perspective from other tools - I agree with that argument.
nginx_access_log_file
andnginx_error_log_file
are currently located in theshared_path
. This is great when deploying to a single node, but whenweb
node isno_release
we have to explicitly create the dir for the log files.I propose the following change:
/var/log/nginx/
- this seems to be the default nginx log path, at least onubuntu
shared_path
directory exists, symlink the log file there so it's conveniently accessible when ssh-ing into the serverBenefits:
nginx:create_log_dir
task obsolete (less code, yaay)