<!-- review: finished -->

<a id="core"></a>

# Core Module

The module provides essential functionality and configuration directives
necessary for the basic operation of the server,
and handles critical tasks such as managing worker processes,
configuring event-driven models,
and processing incoming connections and requests.
It includes key directives for setting up the main process, error
logging, and controlling the behavior of the server at a low level.

<a id="configuration-example-1-1-1-1"></a>

## Configuration Example

```nginx
user www www;
worker_processes 2;

error_log /var/log/error.log info;

events {

    use kqueue; worker_connections 2048;
}
```

<a id="directives-1"></a>

## Directives

<a id="index-0"></a>

<a id="accept-mutex"></a>

### accept_mutex

| [Syntax](https://en.angie.software//angie/docs/configuration/configfile.md#configfile)   | `accept_mutex` `on` | `off`;   |
|------------------------------------------------------------------------------------------|--------------------------------|
| Default                                                                                  | `accept_mutex off;`            |
| [Context](https://en.angie.software//angie/docs/configuration/configfile.md#configfile)  | events                         |

When `accept_mutex` is enabled,
worker processes will accept new connections in turn.
Without this setting, all worker processes are notified of new connections,
which can lead to inefficient use of system resources
if the volume of new connections is low.

#### NOTE
There is no need to enable `accept_mutex` on systems
that support the `EPOLLEXCLUSIVE` flag
or when using the [reuseport](https://en.angie.software//angie/docs/configuration/modules/http/index.md#listen) directive.

<a id="index-1"></a>

<a id="accept-mutex-delay"></a>

### accept_mutex_delay

| [Syntax](https://en.angie.software//angie/docs/configuration/configfile.md#configfile)   | `accept_mutex_delay` time;   |
|------------------------------------------------------------------------------------------|------------------------------|
| Default                                                                                  | `accept_mutex_delay 500ms;`  |
| [Context](https://en.angie.software//angie/docs/configuration/configfile.md#configfile)  | events                       |

If [accept_mutex](#accept-mutex) is enabled,
this directive specifies the maximum time
a worker process will wait
to continue accepting new connections
while another worker process is already handling new connections.

<a id="index-2"></a>

<a id="daemon"></a>

### daemon

| [Syntax](https://en.angie.software//angie/docs/configuration/configfile.md#configfile)   | `daemon` `on` | `off`;   |
|------------------------------------------------------------------------------------------|--------------------------|
| Default                                                                                  | `daemon on;`             |
| [Context](https://en.angie.software//angie/docs/configuration/configfile.md#configfile)  | main                     |

Determines whether Angie should run as a daemon.
This is primarily used during development.

<a id="index-3"></a>

<a id="debug-connection"></a>

### debug_connection

| [Syntax](https://en.angie.software//angie/docs/configuration/configfile.md#configfile)   | `debug_connection` address | CIDR | `unix:`;   |
|------------------------------------------------------------------------------------------|------------------------------------------------|
| Default                                                                                  | —                                              |
| [Context](https://en.angie.software//angie/docs/configuration/configfile.md#configfile)  | events                                         |

Enables debugging logs for specific client connections.
Other connections will use the logging level
set by the [error_log](#error-log) directive.
You can specify connections by IPv4 or IPv6 address, network, or hostname.
For connections using UNIX domain sockets,
use the `unix:` parameter to enable debugging logs.

```nginx
events {

    debug_connection 127.0.0.1;
    debug_connection localhost;
    debug_connection 192.0.2.0/24;
    debug_connection ::1;
    debug_connection 2001:0db8::/32;
    debug_connection unix:;
    #  ...
}
```

#### NOTE
For this directive to work,
Angie must be built with [debugging log](https://en.angie.software//angie/docs/troubleshooting.md#debug-logging) enabled.

<a id="index-4"></a>

<a id="debug-points"></a>

### debug_points

| [Syntax](https://en.angie.software//angie/docs/configuration/configfile.md#configfile)   | `debug_points` `abort` | `stop`;   |
|------------------------------------------------------------------------------------------|------------------------------------|
| Default                                                                                  | —                                  |
| [Context](https://en.angie.software//angie/docs/configuration/configfile.md#configfile)  | main                               |

This directive is used for debugging.

When an internal error occurs,
such as a socket leak during worker process restarts,
enabling `debug_points` will either create a core file (`abort`)
or stop the process (`stop`) for further analysis with a system debugger.

<a id="index-5"></a>

<a id="env"></a>

### env

| [Syntax](https://en.angie.software//angie/docs/configuration/configfile.md#configfile)   | `env` variable[=value];   |
|------------------------------------------------------------------------------------------|---------------------------|
| Default                                                                                  | `env TZ;`                 |
| [Context](https://en.angie.software//angie/docs/configuration/configfile.md#configfile)  | main                      |

By default,
Angie removes all environment variables inherited from its parent process
except for the `TZ` variable.
This directive allows you to preserve some inherited variables,
modify their values, or create new environment variables.

These variables are then:

- inherited during a
  [live upgrade of an executable file](https://en.angie.software//angie/docs/configuration/runtime.md#service-upgrade)
- used by the [Perl](https://en.angie.software//angie/docs/configuration/modules/http/http_perl.md#http-perl) module
- available to worker processes

Note that controlling system libraries in this way may not always be effective,
as libraries often check variables only during initialization,
which occurs before this directive takes effect.
The `TZ` variable is always inherited
and accessible to the [Perl](https://en.angie.software//angie/docs/configuration/modules/http/http_perl.md#http-perl) module
unless explicitly configured otherwise.

Example:

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

#### NOTE
The `ANGIE` environment variable is used internally by Angie
and should not be set directly by the user.

<a id="index-6"></a>

<a id="error-log"></a>

### error_log

| [Syntax](https://en.angie.software//angie/docs/configuration/configfile.md#configfile)   | `error_log` file [level] [[`filter=`type:value] ...];                                                                                                                      |
|------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Default                                                                                  | `error_log logs/error.log error;`<br/>(the path depends on the `--error-log-path` [build option](https://en.angie.software//angie/docs/installation/sourcebuild.md#paths)) |
| [Context](https://en.angie.software//angie/docs/configuration/configfile.md#configfile)  | main, http, mail, stream, server, location                                                                                                                                 |

Configures logging,
allowing multiple logs to be specified at the same configuration level.
If a log file is not explicitly defined at the `main` configuration level,
the default file will be used.

The first parameter specifies the file to store the log.
The special value `stderr` selects the standard error stream.
To configure logging to [syslog](https://en.angie.software//angie/docs/configuration/processing.md#syslog-logging),
use the `"syslog:"` prefix.
To log to a [cyclic memory buffer](https://en.angie.software//angie/docs/troubleshooting.md#cyclic-memory-buffer),
use the `"memory:"` prefix followed by the buffer size;
this is typically used for debugging.

The second parameter sets the logging level, which can be one of the following:
`debug`, `info`, `notice`, `warn`, `error`,
`crit`, `alert`, or `emerg`.
These levels are listed in order of increasing severity.
Setting a log level will capture messages of equal and higher severity:

| Setting   | Levels Captured                                                          |
|-----------|--------------------------------------------------------------------------|
| `debug`   | `debug`, `info`, `notice`, `warn`, `error`,<br/>`crit`, `alert`, `emerg` |
| `info`    | `info`, `notice`, `warn`, `error`,<br/>`crit`, `alert`, `emerg`          |
| `notice`  | `notice`, `warn`, `error`,<br/>`crit`, `alert`, `emerg`                  |
| `warn`    | `warn`, `error`, `crit`, `alert`, `emerg`                                |
| `error`   | `error`, `crit`, `alert`, `emerg`                                        |
| `crit`    | `crit`, `alert`, `emerg`                                                 |
| `alert`   | `alert`, `emerg`                                                         |
| `emerg`   | `emerg`                                                                  |

If this parameter is omitted,
`error` is used as the default logging level.

Optional `filter=` parameters restrict which messages are written to the log.
Supported filters are:

- `filter=file:`prefix matches a source file prefix (for example,
  `ngx_http_access_module.c`);
- `filter=event:`prefix matches an event ID prefix (for example,
  `http.upstream.peer`);
- `filter=tag:`tag matches a tag attached to the log entry.

Multiple `filter=file:` or `filter=event:` parameters are matched
by prefix, and any match allows the message to pass. Multiple
`filter=tag:` parameters require all tags to be present.
Tags can be added automatically by modules (for example,
`http`, `stream`, `mail`, `upstream`,
`peer`, `subrequest`) and by
[error_log_user_tag](https://en.angie.software//angie/docs/configuration/modules/http/index.md#error-log-user-tag) directives.

#### NOTE
For the `debug` logging level to work,
Angie must be built with [debugging log](https://en.angie.software//angie/docs/troubleshooting.md#debug-logging) enabled.

Each entry in the error log has the following format:

```text
timestamp [level] PID#TID: *request_id message
```

Where:

- `timestamp` — date and time of the event
- `level` — logging level of the event
- `PID#TID` — process and thread identifiers
- `*request_id` — unique request identifier (if applicable)
- `message` — error or event message text

<a id="index-7"></a>

<a id="events"></a>

### events

| [Syntax](https://en.angie.software//angie/docs/configuration/configfile.md#configfile)   | `events` { ... };   |
|------------------------------------------------------------------------------------------|---------------------|
| Default                                                                                  | —                   |
| [Context](https://en.angie.software//angie/docs/configuration/configfile.md#configfile)  | main                |

Provides the configuration file context for directives
that affect connection processing.

<a id="index-8"></a>

<a id="include"></a>

### include

| [Syntax](https://en.angie.software//angie/docs/configuration/configfile.md#configfile)   | `include` file | mask;   |
|------------------------------------------------------------------------------------------|--------------------------|
| Default                                                                                  | —                        |
| [Context](https://en.angie.software//angie/docs/configuration/configfile.md#configfile)  | any                      |

Includes another file, or files that match the specified mask,
into the configuration.
The included files must contain syntactically correct directives and blocks.

Example:

```nginx
include mime.types;
include vhosts/*.conf;
```

<a id="index-9"></a>

<a id="load-module"></a>

### load_module

| [Syntax](https://en.angie.software//angie/docs/configuration/configfile.md#configfile)   | `load_module` file;   |
|------------------------------------------------------------------------------------------|-----------------------|
| Default                                                                                  | —                     |
| [Context](https://en.angie.software//angie/docs/configuration/configfile.md#configfile)  | main                  |

Loads a dynamic module from the specified file.
If a relative path is provided, it is interpreted based on the
`--prefix` [build option](https://en.angie.software//angie/docs/installation/sourcebuild.md#configure). To verify the path:

```console
$ sudo angie -V
```

Example:

```nginx
load_module modules/ngx_mail_module.so;
```

If a dynamic module was built for a different Angie build, loading fails with an
error like: "module "..." was built for "..." but you are running "Angie"".

<a id="index-10"></a>

<a id="lock-file"></a>

### lock_file

| [Syntax](https://en.angie.software//angie/docs/configuration/configfile.md#configfile)   | `lock_file` file;                                                                                                                                                |
|------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Default                                                                                  | `lock_file logs/angie.lock;`<br/>(the path depends on the `--lock-path` [build option](https://en.angie.software//angie/docs/installation/sourcebuild.md#paths)) |
| [Context](https://en.angie.software//angie/docs/configuration/configfile.md#configfile)  | main                                                                                                                                                             |

Angie uses a locking mechanism to implement [accept_mutex](#accept-mutex)
and serialize access to shared memory.
On most systems, locks are managed using atomic operations,
making this directive unnecessary.
On certain systems, however, an alternative lock file mechanism is used.
This directive sets a prefix for lock file names.

<a id="index-11"></a>

<a id="master-process"></a>

### master_process

| [Syntax](https://en.angie.software//angie/docs/configuration/configfile.md#configfile)   | `master_process` `on` | `off`;   |
|------------------------------------------------------------------------------------------|----------------------------------|
| Default                                                                                  | `master_process on;`             |
| [Context](https://en.angie.software//angie/docs/configuration/configfile.md#configfile)  | main                             |

Determines whether worker processes are started.
This directive is intended for Angie developers.

<a id="index-12"></a>

<a id="multi-accept"></a>

### multi_accept

| [Syntax](https://en.angie.software//angie/docs/configuration/configfile.md#configfile)   | `multi_accept` `on` | `off`;   |
|------------------------------------------------------------------------------------------|--------------------------------|
| Default                                                                                  | `multi_accept off;`            |
| [Context](https://en.angie.software//angie/docs/configuration/configfile.md#configfile)  | events                         |

| `on`   | A worker process will accept all new connections simultaneously.   |
|--------|--------------------------------------------------------------------|
| `off`  | A worker process will accept one new connection at a time.         |

#### NOTE
This directive is ignored
if the [kqueue](https://en.angie.software//angie/docs/configuration/processing.md#kqueue) connection processing method is used,
as it provides the number of new connections ready to be accepted.

<a id="index-13"></a>

<a id="pcre-jit"></a>

### pcre_jit

| [Syntax](https://en.angie.software//angie/docs/configuration/configfile.md#configfile)   | `pcre_jit` `on` | `off`;   |
|------------------------------------------------------------------------------------------|----------------------------|
| Default                                                                                  | `pcre_jit off;`            |
| [Context](https://en.angie.software//angie/docs/configuration/configfile.md#configfile)  | main                       |

Enables or disables "just-in-time compilation" (PCRE JIT)
for regular expressions known at the time of configuration parsing.

PCRE JIT can significantly accelerate regular expression processing.

#### NOTE
JIT is available in PCRE libraries from version 8.20,
provided they are built with the `--enable-jit` configuration option.
When Angie is built with the PCRE library (`--with-pcre=`),
JIT support is enabled using the `--with-pcre-jit` option.

<a id="index-14"></a>

<a id="pid"></a>

### pid

| [Syntax](https://en.angie.software//angie/docs/configuration/configfile.md#configfile)   | `pid` file | `off`;                                                                                                                                      |
|------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------|
| Default                                                                                  | `pid logs/angie.pid;`<br/>(the path depends on the `--pid-path` [build option](https://en.angie.software//angie/docs/installation/sourcebuild.md#paths)) |
| [Context](https://en.angie.software//angie/docs/configuration/configfile.md#configfile)  | main                                                                                                                                                     |

Specifies the file that will store the ID of the Angie main process.
The file is created atomically, which ensures its contents are always correct.
The `off` setting disables the creation of this file.

#### NOTE
If the file setting is modified during reconfiguration
but points to a symlink of the previous PID file,
the file will not be recreated.

<a id="index-15"></a>

<a id="ssl-engine"></a>

### ssl_engine

| [Syntax](https://en.angie.software//angie/docs/configuration/configfile.md#configfile)   | `ssl_engine` device;   |
|------------------------------------------------------------------------------------------|------------------------|
| Default                                                                                  | —                      |
| [Context](https://en.angie.software//angie/docs/configuration/configfile.md#configfile)  | main                   |

Specifies the name of the hardware SSL accelerator.

<a id="index-16"></a>

<a id="ssl-object-cache-inheritable"></a>

### ssl_object_cache_inheritable

| [Syntax](https://en.angie.software//angie/docs/configuration/configfile.md#configfile)   | `ssl_object_cache_inheritable` `on` | `off`;   |
|------------------------------------------------------------------------------------------|------------------------------------------------|
| Default                                                                                  | `ssl_object_cache_inheritable on;`             |
| [Context](https://en.angie.software//angie/docs/configuration/configfile.md#configfile)  | main                                           |

If enabled, SSL objects (SSL certificates, secret keys, trusted CA certificates,
CRL lists) are inherited across configuration reloads.

SSL objects loaded from files are inherited if their modification time and file
index have not changed since the previous configuration load. Secret keys
specified as `engine:name:id` are never inherited, while secret keys
specified as `data:value` are always inherited.

SSL objects loaded from variables cannot be inherited.

Example:

```nginx
ssl_object_cache_inheritable on;

http {
    server {
        ssl_certificate     example.com.crt;
        ssl_certificate_key example.com.key;
    }
}
```

<a id="index-17"></a>

<a id="thread-pool"></a>

### thread_pool

| [Syntax](https://en.angie.software//angie/docs/configuration/configfile.md#configfile)   | `thread_pool` name `threads=`number [`max_queue=`number];   |
|------------------------------------------------------------------------------------------|-------------------------------------------------------------|
| Default                                                                                  | `thread_pool default threads=32 max_queue=65536;`           |
| [Context](https://en.angie.software//angie/docs/configuration/configfile.md#configfile)  | main                                                        |

Defines the name and parameters of a thread pool
used for multi-threaded reading and sending of files
[without blocking](https://en.angie.software//angie/docs/configuration/modules/http/index.md#aio) worker processes.

The `threads` parameter defines the number of threads in the pool.

If all threads in the pool are busy executing tasks, new tasks wait in a queue.
The `max_queue` parameter limits the number of tasks
allowed to be waiting in the queue.
By default, up to 65536 tasks can be in the queue.
When the queue overflows, the task is completed with an error.

<a id="index-18"></a>

<a id="timer-resolution"></a>

### timer_resolution

| [Syntax](https://en.angie.software//angie/docs/configuration/configfile.md#configfile)   | `timer_resolution` interval;   |
|------------------------------------------------------------------------------------------|--------------------------------|
| Default                                                                                  | —                              |
| [Context](https://en.angie.software//angie/docs/configuration/configfile.md#configfile)  | main                           |

Reduces timer resolution in worker processes,
thus reducing the number of `gettimeofday()` system calls.
By default, `gettimeofday()` is called each time a kernel event is received.
With reduced resolution, `gettimeofday()` is only called once per specified interval.

Example:

```nginx
timer_resolution 100ms;
```

Internal implementation of the interval depends on the method used:

- the `EVFILT_TIMER` filter if [kqueue](https://en.angie.software//angie/docs/configuration/processing.md#kqueue) is used;
- `timer_create()` if [eventport](https://en.angie.software//angie/docs/configuration/processing.md#eventport) is used;
- `setitimer()` otherwise.

<a id="index-19"></a>

<a id="use"></a>

### use

| [Syntax](https://en.angie.software//angie/docs/configuration/configfile.md#configfile)   | `use` method;   |
|------------------------------------------------------------------------------------------|-----------------|
| Default                                                                                  | —               |
| [Context](https://en.angie.software//angie/docs/configuration/configfile.md#configfile)  | events          |

Specifies the method to use for [connection processing](https://en.angie.software//angie/docs/configuration/processing.md#methods-use).
There is normally no need to specify it explicitly,
because Angie will by default use the most efficient method.

<a id="index-20"></a>

<a id="user"></a>

### user

| [Syntax](https://en.angie.software//angie/docs/configuration/configfile.md#configfile)   | `user` user [group];                                       |
|------------------------------------------------------------------------------------------|------------------------------------------------------------|
| Default                                                                                  | `user <build parameter --user> <build parameter --group>;` |
| [Context](https://en.angie.software//angie/docs/configuration/configfile.md#configfile)  | main                                                       |

Defines user and group credentials used by worker processes
(see also [build parameters](https://en.angie.software//angie/docs/installation/sourcebuild.md#configure)).
If group is omitted, a group whose name equals that of user is used.

<a id="index-21"></a>

<a id="worker-aio-requests"></a>

### worker_aio_requests

| [Syntax](https://en.angie.software//angie/docs/configuration/configfile.md#configfile)   | `worker_aio_requests` number;   |
|------------------------------------------------------------------------------------------|---------------------------------|
| Default                                                                                  | `worker_aio_requests 32;`       |
| [Context](https://en.angie.software//angie/docs/configuration/configfile.md#configfile)  | events                          |

When using [aio](https://en.angie.software//angie/docs/configuration/modules/http/index.md#aio) with the [epoll](https://en.angie.software//angie/docs/configuration/processing.md#epoll) connection processing method,
sets the maximum number of outstanding asynchronous I/O operations
for a single worker process.

<a id="index-22"></a>

<a id="worker-connections"></a>

### worker_connections

| [Syntax](https://en.angie.software//angie/docs/configuration/configfile.md#configfile)   | `worker_connections` number;   |
|------------------------------------------------------------------------------------------|--------------------------------|
| Default                                                                                  | `worker_connections 512;`      |
| [Context](https://en.angie.software//angie/docs/configuration/configfile.md#configfile)  | events                         |

Sets the maximum number of simultaneous connections that can be opened by a worker process.

It should be kept in mind that this number includes all connections
(e.g. connections with proxied servers, among others),
not only connections with clients.
Another consideration is that the actual number of simultaneous connections
cannot exceed the current limit on the maximum number of open files,
which can be changed by [worker_rlimit_nofile](#worker-rlimit-nofile).

<a id="index-23"></a>

<a id="worker-cpu-affinity"></a>

### worker_cpu_affinity

| [Syntax](https://en.angie.software//angie/docs/configuration/configfile.md#configfile)   | `worker_cpu_affinity` cpumask ...;<br/><br/>`worker_cpu_affinity` auto [cpumask];   |
|------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------|
| Default                                                                                  | —                                                                                   |
| [Context](https://en.angie.software//angie/docs/configuration/configfile.md#configfile)  | main                                                                                |

Binds worker processes to the sets of CPUs.
Each CPU set is represented by a bitmask of allowed CPUs.
There should be a separate set defined for each of the worker processes.
By default, worker processes are not bound to any specific CPUs.

For example:

```nginx
worker_processes    4;
worker_cpu_affinity 0001 0010 0100 1000;
```

This configuration binds each worker process to a separate CPU.

Alternatively:

```nginx
worker_processes    2;
worker_cpu_affinity 0101 1010;
```

This binds the first worker process to CPU0 and CPU2,
and the second worker process to CPU1 and CPU3.
This setup is suitable for hyper-threading.

The special value `auto`
allows binding worker processes automatically to available CPUs:

```nginx
worker_processes auto;
worker_cpu_affinity auto;
```

The optional mask parameter can be used to limit the CPUs
available for automatic binding:

```nginx
worker_cpu_affinity auto 01010101;
```

#### NOTE
The directive is only available on FreeBSD and Linux.

<a id="index-24"></a>

<a id="worker-priority"></a>

### worker_priority

| [Syntax](https://en.angie.software//angie/docs/configuration/configfile.md#configfile)   | `worker_priority` number;   |
|------------------------------------------------------------------------------------------|-----------------------------|
| Default                                                                                  | `worker_priority 0;`        |
| [Context](https://en.angie.software//angie/docs/configuration/configfile.md#configfile)  | main                        |

Defines the scheduling priority for worker processes like it is done
by the **nice** command: a negative number
means higher priority.
Allowed range normally varies from -20 to 20.

Example:

```nginx
worker_priority -10;
```

<a id="index-25"></a>

<a id="worker-processes"></a>

### worker_processes

| [Syntax](https://en.angie.software//angie/docs/configuration/configfile.md#configfile)   | `worker_processes` number | `auto`;   |
|------------------------------------------------------------------------------------------|---------------------------------------|
| Default                                                                                  | `worker_processes 1;`                 |
| [Context](https://en.angie.software//angie/docs/configuration/configfile.md#configfile)  | main                                  |

Defines the number of worker processes.

The optimal value depends on many factors including (but not limited to)
the number of CPU cores, the number of hard disk drives that store data,
and load pattern.
When one is in doubt, setting it to the number of available CPU cores
would be a good start (the value "`auto`" will try to autodetect it).

<a id="index-26"></a>

<a id="worker-rlimit-core"></a>

### worker_rlimit_core

| [Syntax](https://en.angie.software//angie/docs/configuration/configfile.md#configfile)   | `worker_rlimit_core` size;   |
|------------------------------------------------------------------------------------------|------------------------------|
| Default                                                                                  | —                            |
| [Context](https://en.angie.software//angie/docs/configuration/configfile.md#configfile)  | main                         |

Changes the limit on the largest size of a core file (`RLIMIT_CORE`)
for worker processes.
Used to increase the limit without restarting the main process.

<a id="index-27"></a>

<a id="worker-rlimit-nofile"></a>

### worker_rlimit_nofile

| [Syntax](https://en.angie.software//angie/docs/configuration/configfile.md#configfile)   | `worker_rlimit_nofile` number;   |
|------------------------------------------------------------------------------------------|----------------------------------|
| Default                                                                                  | —                                |
| [Context](https://en.angie.software//angie/docs/configuration/configfile.md#configfile)  | main                             |

Changes the limit on the maximum number of open files (`RLIMIT_NOFILE`)
for worker processes.
Used to increase the limit without restarting the main process.

<a id="index-28"></a>

<a id="worker-shutdown-timeout"></a>

### worker_shutdown_timeout

| [Syntax](https://en.angie.software//angie/docs/configuration/configfile.md#configfile)   | `worker_shutdown_timeout` time;   |
|------------------------------------------------------------------------------------------|-----------------------------------|
| Default                                                                                  | —                                 |
| [Context](https://en.angie.software//angie/docs/configuration/configfile.md#configfile)  | main                              |

Configures a timeout in seconds for a graceful shutdown of worker processes.
When the specified time expires,
Angie will try to close all the connections currently open
to facilitate shutdown.

Graceful shutdown is initiated by sending a [QUIT signal](https://en.angie.software//angie/docs/configuration/runtime.md#control-signals) to the main process, which instructs worker processes
to stop accepting new connections and allows existing connections to complete.
Worker processes continue to handle active requests until they finish,
then shut down gracefully. If connections remain open
longer than `worker_shutdown_timeout`, Angie will forcibly close these
connections to complete the shutdown.
Also, client keep-alive connections are closed only if they have been
idle for at least the time specified by [lingering_timeout](https://en.angie.software//angie/docs/configuration/modules/http/index.md#lingering-timeout).

<a id="index-29"></a>

<a id="working-directory"></a>

### working_directory

| [Syntax](https://en.angie.software//angie/docs/configuration/configfile.md#configfile)   | `working_directory` directory;   |
|------------------------------------------------------------------------------------------|----------------------------------|
| Default                                                                                  | —                                |
| [Context](https://en.angie.software//angie/docs/configuration/configfile.md#configfile)  | main                             |

Defines the current working directory for a worker process.
It is primarily used when writing a core file,
in which case a worker process should have write permission for the
specified directory.