FAQ

Page Discussion History

MainModuleJa

Contents

Nginxメインモジュール

これらはNginxを機能させる基本的なディレクティブです。

ディレクティブ

  • [#daemon daemon]
  • [#env env]
  • [#debug_points debug_points]
  • [#error_log error_log]
  • [#log_not_found log_not_found]
  • [#include include]
  • [#lock_file lock_file]
  • [#master_process master_process]
  • [#pid pid]
  • [#ssl_engine ssl_engine]
  • [#timer_resolution timer_resolution]
  • [#user user]
  • [#worker_cpu_affinity worker_cpu_affinity]
  • [#worker_priority worker_priority]
  • [#worker_processes worker_processes]
  • [#worker_rlimit_core worker_rlimit_core]
  • [#worker_rlimit_nofile worker_rlimit_nofile]
  • [#worker_rlimit_sigpending worker_rlimit_sigpending]
  • [#working_directory working_directory]

Template:Anchor

daemon

構文: daemon on | off

デフォルト値: on

daemon  off;

"daemon"や"master_process"ディレクティブは生産モードでは使用しないでください。これらは主に開発時に使用されるものです。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.


Template:Anchor

env

構文: env VAR|VAR=VALUE

デフォルト値: TZ

コンテキスト: main

The instruction allows to limit a set of variables of environment, to change it values or to create new variables for following cases:

  • ダウンタイムなしにバイナリアップグレードする 際の変数の継承
  • ngx_http_perl_module での変数の使用
  • Use of variables 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 module ngx_http_perl_module.

Example of use:

env  MALLOC_OPTIONS;
env  PERL5LIB=/data/site/modules;
env  OPENSSL_ALLOW_PROXY_CERTS=1;


Template:Anchor

debug_points

構文: debug_points [stop | abort]

デフォルト値: none

debug_points stop;

There are some assertion points inside nginx that allow to stop nginx to attach the debugger, or to abort and to create the core file.


Template:Anchor

error_log

構文: error_log file [ debug | info | notice | warn | error | crit ]

デフォルト値: ${prefix}/logs/error.log

If you've built Nginx with --with-debug, you may also use:

error_log LOGFILE [ debug_core | debug_alloc | debug_mutex | debug_event
]: | debug_http | debug_imap ;


Template:Anchor

log_not_found

構文: log_not_found on | off

デフォルト値: on

コンテキスト: location

Enables or disables logging of requests that resolve into 404 status code. Can be used to prevent nginx from logging requests for the missing robots.txt and favicon.ico files. Example:

location = /robots.txt {
: log_not_found  off;
}


Template:Anchor

include

構文: include file | *

デフォルト値: none

You can include any configuration files for what ever purpose you want.

Since 0.4.4, the include directive also supports filename globbing:

include vhosts/*.conf;

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.

Template:Anchor

lock_file

構文: lock_file file

デフォルト値: compile-time option

lock_file  /var/log/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.


Template:Anchor

master_process

構文: master_process on | off

デフォルト値: on

master_process  off;

Do not use the "daemon" and "master_process" directives in a production mode, these options are mainly used for development only.


Template:Anchor

pid

構文: pid file

デフォルト値: compile-time option

Example:

pid /var/log/nginx.pid;

The pid-file. It can be used for the kill-command to send signals to nginx, eg: to reload the config: kill -HUP <code>cat /var/log/nginx.pid\</code>

Template:Anchor

ssl_engine

構文: ssl_engine engine

デフォルト値: system dependent

Here you can set your preferred openssl engine if any available. You can figure out which one do you have with the commandline tool: openssl engine -t

For example:

$ openssl engine -t
(cryptodev) BSD cryptodev engine
: [ available ] 
(dynamic) Dynamic engine loading support
: [ unavailable ] 

Template:Anchor

timer_resolution

構文: timer_resolution t

デフォルト値: none

Example:

timer_resolution  100ms;

The directive allows to decrease number gettimeofday() syscalls. By default gettimeofday() is called after each return from kevent(), epoll, /dev/poll, select(), poll().

But if you need an exact time in logs when logging $upstream_response_time, or $msec variables, then you should use timer_resolution.


Template:Anchor

user

構文: user user [group]

デフォルト値: nobody nobody

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.

Example:

user www users;

Template:Anchor

worker_cpu_affinity

構文: worker_cpu_affinity cpumask [cpumask...]

デフォルト値: none

Linux only.

With this option you can bind the worker process to a CPU, it calls sched_setaffinity().

For example,

worker_processes     4;
worker_cpu_affinity 0001 0010 0100 1000;

Bind each worker process to one CPU only.

worker_processes     2;
worker_cpu_affinity 0101 1010;

Bind the first worker to CPU0/CPU2, bind the second worker to CPU1/CPU3. This is suitable for HTT.


Template:Anchor

worker_priority

構文: worker_priority [-] number

デフォルト値: on

With this option you can give to all worker processes the priority (nice) you need/wish, it calls setpriority().


Template:Anchor

worker_processes

構文: worker_processes number

デフォルト値: 1

e.g.:

worker_processes 5;

nginx has the ability to use more than one worker process for several reasons:

  1. to use SMP
  2. to decrease latency when workers blockend on disk I/O
  3. to limit number of connections per process when select()/poll() is used

The worker_processes and worker_connections from the event sections allows you to calculate maxclients value:

max_clients = worker_processes * worker_connections


Template:Anchor

worker_rlimit_core

構文: worker_rlimit_core size

デフォルト値:

Maximum size of core file per worker;


Template:Anchor

worker_rlimit_nofile

構文: worker_rlimit_nofile limit

デフォルト値:

Specifies the value for maximum file descriptors that can be opened by this process.


Template:Anchor

worker_rlimit_sigpending

構文: worker_rlimit_sigpending limit デフォルト値:

(Since Linux 2.6.8) Specifies the limit on the number of signals that may be queued for the real user ID of the calling process.


Template:Anchor

working_directory

構文: working_directory path

デフォルト値: --prefix

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


References