вот scee.conf -
pid ./pid;
error_log ./error_log debug;
events {
worker_connections 1024;
}
http {
access_log ./access_log;
server {
listen 31415;
}
}
Я выполняю его использование
nginx -c scee.conf -p .
(выполненный из каталога, в котором это находится),
Большая часть материала зарегистрирована к error.log
в том же каталоге как файл конфигурации, но загадочно следующая строка продолжает регистрироваться к /var/log/nginx/error.log
каждый раз nginx перезапущен -
2015/05/06 21:41:39 [notice] 2231#0: signal process started
или подобный.
Это является раздражающим, поскольку это требует, чтобы/var/log/nginx был перезаписываем пользователем, работающим nginx. Что продолжается здесь?
Вывод nginx-V
nginx version: nginx/1.4.6 (Ubuntu)
built by gcc 4.8.2 (Ubuntu 4.8.2-19ubuntu1)
TLS SNI support enabled
configure arguments: --with-cc-opt='-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro' --prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-debug --with-pcre-jit --with-ipv6 --with-http_ssl_module --with-http_stub_status_module --with-http_realip_module --with-http_addition_module --with-http_dav_module --with-http_geoip_module --with-http_gzip_static_module --with-http_image_filter_module --with-http_spdy_module --with-http_sub_module --with-http_xslt_module --with-mail --with-mail_ssl_module
Что - флаг компилятора пути журнала ошибок, делающий здесь? Это просто управляет местоположением по умолчанию журналов, если у Вас нет error_log директивы в Вашем файле конфигурации?
Проверьте, есть ли в вашей конфигурации более одного блока сервера. В моем случае я думаю, что это было вызвано перенаправлением HTTP, как показано ниже. HTTP-запросы записывались в журнал по умолчанию, но HTTPS-запросы регистрировались там, где я ожидал.
server {
listen 80 default_server;
listen [::]:80 default_server ipv6only=on;
return 301 https://example.com$request_uri;
}
server {
listen 443;
access_log /path/to/my.log;
...
}