Nginx HTTP Server: Base Module Directives

Name and context

Syntax and description

daemon

Accepted values: on or off

Syntax:

daemon on;

Default value: on

Enables or disables daemon mode. If you disable it, the program will not be started in the background; it will stay in the foreground when launched from the shell.

debug_points

Accepted values: stop or abort

Syntax:

debug_points stop;

Default value: None.

Activates debug points in Nginx. Use stop to interrupt the

application when a debug point comes about in order to attach a debugger. Use abort to abort the debug point and create a core dump file.

To disable this option, simply do not use the directive.

env

Syntax:

env MY_VARIABLE;

env MY_VARIABLE=my_value;

Lets you (re)define environment variables.

error_log

Context: main,

http, server,

and location

Syntax:

error_log /file/path level;

Default value: logs/error.log error.

Where level is one of the following values: debug, info, notice, warn, error, and crit (from most to least detailed: debug provides frequent log entries, crit only reports critical errors).

Enables error logging at different levels: Application, HTTP server, virtual host, and virtual host directory.

By redirecting the log output to /dev/null, you can disable

error logging. Use the following directive at the root of the configuration file:

error_log /dev/null crit;

lock_file

Syntax: File path

lock_file logs/nginx.lock;

Default value: Defined at compile time

Use a lock file for mutual exclusion. Disabled by default, unless you enabled it at compile time.

log_not_found

Context: main,

http, server, and

location

Accepted values: on or off

log_not_found on;

Default value: on

Enables or disables logging of 404 not found HTTP errors. If your logs get filled with 404 errors due to missing favicon.ico or robots.txt files, you might want to turn this off.

master_process

Accepted values: on or off

master_process on;

Default value: on

If enabled, Nginx will start multiple processes: A main process

(the master process) and worker processes. If disabled, Nginx

works with a unique process. This directive should be used for

testing purposes only as it disables the master process-clients

thus cannot connect to your server.

pid

Syntax: File path

pid logs/nginx.pid;

Default value: Defined at compile time.

Path of the pid file for the Nginx daemon. The default value can be

configured at compile time.

ssl_engine

Syntax: Character string

ssl_engine enginename;

Default value: None

Where enginename is the name of an available hardware SSL

accelerator on your system. To check for available hardware SSL

accelerators, run this command from the shell:

openssl engine -t

thread_stack_size

Syntax: Numeric (size)

thread_stack_size 1m;

Default value: None

Defines the size of thread stack; please refer to the

worker_threads directive below

timer_resolution

Syntax: Numeric (time)

timer_resolution 100ms;

Default value: None

Controls the interval between system calls to gettimeofday()

to synchronize the internal clock. If this value is not specified, the

clock is refreshed after each kernel event notification.

user

Syntax:

user username groupname;

user username;

Default value: Defined at compile time. If still undefined, the user

and group of the Nginx master process are used.

Lets you define the user account and optionally the user group

used for starting the Nginx worker processes.

worker_threads

Syntax: Numeric

worker_threads 8;

Default value: None

Defines the amount of threads per worker process.

Warning! Threads are disabled by default. The author stated that

"the code is currently broken".

worker_cpu_affinity

Syntax:

worker_cpu_affinity 1000 0100 0010 0001;

worker_cpu_affinity 10 10 01 01;

worker_cpu_affinity;

Default value: None

This directive works in conjunction with worker_processes. It lets you affect worker processes to CPU cores.

There are as many series of digit blocks as worker processes; there are as many digits in a block as your CPU has cores.

If you configure Nginx to use three worker processes, there are three blocks of digits. For a dual-core CPU, each block has two digits.

worker_cpu_affinity 01 01 10;

The first block (01) indicates that the first worker process should be

affected to the second core.

The second block (01) indicates that the second worker process

should be affected to the second core.

The third block (10) indicates that the third worker process should

be affected to the first core.

Note that affinity is only recommended for multi-core CPUs, not

for processors with hyper-treading or similar technologies.

worker_priority

Syntax: Numeric

worker_priority 0;

Default value: 0

Defines the priority of the worker processes, from -20 (highest)

to 19 (lowest). The default value is 0. Note that kernel processes

run at priority level -5, so it's not recommended that you set the

priority to -5 or less.

worker_processes

Syntax: Numeric

worker_processes 4;

Default value: 1

Defines the amount of worker processes. Nginx offers to separate

the treatment of requests into multiple processes. The default value

is 1, but it's recommended to increase this value if your CPU has

more than one core.

Besides, if a process gets blocked due to slow I/O operations,

incoming requests can be delegated to the other worker processes.

worker_rlimit_core

Syntax: Numeric (size)

worker_rlimit_core 100m;

Default value: None

Defines the size of core files per worker process.

worker_rlimit_nofile

Syntax: Numeric

worker_rlimit_nofile 10000;

Default value: None

Defines the amount of files a worker process may use

simultaneously.

worker_rlimit_sigpending

Syntax: Numeric

worker_rlimit_sigpending 10000;

Default value: None

Defines the amount of signals that can be queued per user (user ID

of the calling process). If the queue is full, signals are ignored past

this limit.

working_directory

Syntax: Directory path

working_directory /usr/local/nginx/;

Default value: The prefi x switch defined at compile time.

Working directory used for worker processes; only used to define

the location of core files. The worker process user account (user

directive) must have write permissions on this folder in order to be

able to write core files.