Nginx supports separate error logging per virtual host. This is a unique feature, which [http://www.wikivs.com/wiki/Lighttpd_vs_nginx#Separated_error_logging_per_virtual_server lighttpd refuses to implement]. For an example of separate error logging per server, see [[SeparateErrorLoggingPerVirtualHost]] and this [http://thread.gmane.org/gmane.comp.web.nginx.english/9097/focus=9099 mailing list thread on separating error logging per virtual host].

If you've built Nginx with <code>--with-debug</code>, you may also use:

If you've built Nginx with <code>--with-debug</code>, you may also use:

If the master process is run as root, then nginx will setuid()/setgid() to USER/GROUP. If GROUP is not specified, then nginx uses the same name as USER. By default it's <code>nobody</code> user and <code>nobody</code> or <code>nogroup</code> group or the <code>--user=USER</code> and <code>--group=GROUP</code> from the <code>./configure</code> script.

If the master process is run as root, then nginx will setuid()/setgid() to USER/GROUP. If GROUP is not specified, then nginx uses the same name as USER. By default it's <code>nobody</code> user and <code>nobody</code> or <code>nogroup</code> group or the <code>--user=USER</code> and <code>--group=GROUP</code> from the <code>./configure</code> script.

This is the working directory for the workers. It's used for core files only and [[Debugging]] Nginx. nginx uses absolute paths only, all relative paths in configuration files are relative to <code>--prefix==PATH</code>.

This is the working directory for the workers. It's used for core files only and [[Debugging]] Nginx. nginx uses absolute paths only, all relative paths in configuration files are relative to <code>--prefix==PATH</code>.

Line 275:

Line 239:

= References =

= References =

+

[http://nginx.org/en/docs/ngx_core_module.html Original Documentation]

Directives

daemon

Do not use the daemon or master_process directives in a production mode; these options are used for development only. You can use daemon off safely in production mode with runit/daemontools, however you can't do a graceful upgrade. master_process off should never be used in production.

for use by working processes. However it is necessary to keep in mind, that management of behaviour of system libraries in a similar way probably not always as frequently libraries use variables only during initialization, that is still before they can be set by means of the given instruction. Exception to it is the above described updating an executed file with zero downtime.

If variable TZ is not described obviously it is always inherited and is always accessible to the embedded Perl module.

Also note that as of version 0.7.53, nginx will use a compiled-in default error log location until it has read the config file. If the user running nginx doesn't have write permission to this log location, nginx will raise an alert like this:

Note that until version 0.6.7, paths are relative to what was specified to configure via the --prefix=<PATH> directive, which by default is /usr/local/nginx. If you didn't set this when you compiled Nginx, then use absolute paths.

Since version 0.6.7, paths are relative to directory of nginx configuration file nginx.conf, but not to nginx prefix directory.

lock_file

nginx uses accept mutex to serialize accept() syscalls. If nginx is built by gcc, Intel C++, or SunPro C++ compilers on i386, amd64, sparc64, and ppc64, then nginx uses the atomic instructions to implement the mutex. In other cases the lock file would be used.

user

If the master process is run as root, then nginx will setuid()/setgid() to USER/GROUP. If GROUP is not specified, then nginx uses the same name as USER. By default it's nobody user and nobody or nogroup group or the --user=USER and --group=GROUP from the ./configure script.

working_directory

This is the working directory for the workers. It's used for core files only and Debugging Nginx. nginx uses absolute paths only, all relative paths in configuration files are relative to --prefix==PATH.