However it’s still logging to /var/log/nginx/access.log instead of
/var/log/nginx/$vhost.access.log.
[root@sg ~]# cd /var/log/nginx/
[root@sg nginx]# inotifywait -r -m .
Setting up watches. Beware: since -r was given, this may take a
while!
Watches established.
./ MODIFY access.log
./ MODIFY access.log
root /srv/www/$vhost; works, but not access_log /var/log/nginx/$vhost.access.log;.
What am I missing?
Could my configuration upon Nginx 1.4 Virtual hosting be otherwise
improved, without breaking it into individual server blocks?
: The file path can contain variables (0.7.6+), but such logs have some
: constraints:
:
: - the user whose credentials are used by worker processes should have
: permissions to create files in a directory with such logs;
:
: - buffered writes do not work;
:
: - the file is opened and closed for each log write. However, since the
: descriptors of frequently used files can be stored in a cache, writing
to the
: old file can continue during the time specified by the
open_log_file_cache
: directive’s valid parameter
:
: - during each log write the existence of the request’s root directory
is
: checked, and if it does not exist the log is not created. It is thus a
good
: idea to specify both root and access_log on the same level:
On Tue, Aug 27, 2013 at 03:32:29PM +0400, Maxim D. wrote:
: - the user whose credentials are used by worker processes should have
: permissions to create files in a directory with such logs;
/var/log/nginx has +x on http user, so that’s fine.
: - buffered writes do not work;
Not sure what that means.
: - the file is opened and closed for each log write. However, since the
: descriptors of frequently used files can be stored in a cache, writing to the
: old file can continue during the time specified by the open_log_file_cache
: directive’s valid parameter
IIUC there can be delay. No problem.
: - during each log write the existence of the request’s root directory is
: checked, and if it does not exist the log is not created. It is thus a good
: idea to specify both root and access_log on the same level:
The root is served fine…
I don’t understand how I fix my problem.
Or are you saying there isn’t a way to fix it?
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.