Run-Time Control

To run Angie use systemd with following command:

$ sudo service angie start

It’s recommended to check configuration syntax in prior, here is how:

$ sudo angie -t && sudo service angie start

To reload:

$ sudo angie -t && sudo service angie reload

To stop:

$ sudo service angie stop

On install, run the following to make sure Angie is up and running:

$ curl localhost:80

Note

Ways of running the open-source version of Angie depend on the installation method.

Angie has one master process and several worker processes. The main purpose of the master process is to read and evaluate configuration, and maintain worker processes. Worker processes do actual processing of requests. Angie employs event-based model and OS-dependent mechanisms to efficiently distribute requests among worker processes. The number of worker processes is defined in the configuration file and may be fixed for a given configuration or automatically adjusted to the number of available CPU cores (see worker_processes).

Using Signals

Angie can be controlled with signals as well. The process ID of the master process is written to the file /var/run/angie.pid by default. This name may be changed at configuration time, or in angie.conf using the pid directive. The master process supports the following signals:

TERM, INT	fast shutdown
QUIT	graceful shutdown
HUP	changing configuration, keeping up with a changed time zone (only for FreeBSD and Linux), starting new worker processes with a new configuration, graceful shutdown of old worker processes
USR1	re-opening log files
USR2	upgrading an executable file
WINCH	graceful shutdown of worker processes

Individual worker processes can be controlled with signals as well, though it is not required. The supported signals are:

TERM, INT	fast shutdown
QUIT	graceful shutdown
USR1	re-opening log files
WINCH	abnormal termination for debugging (requires debug_points to be enabled)

Changing Configuration

In order for Angie to re-read the configuration file, a HUP signal should be sent to the master process. The master process first checks the syntax validity, then tries to apply new configuration, that is, to open log files and new listen sockets. If this fails, it rolls back changes and continues to work with old configuration. If this succeeds, it starts new worker processes, and sends messages to old worker processes requesting them to shut down gracefully. Old worker processes close listen sockets and continue to service old clients. After all clients are serviced, old worker processes are shut down.

Angie tracks configuration changes per each process. Generation numbers start with 1 when the server is started; the numbers are incremented at each configuration reload and appear in process titles:

sudo angie
ps aux | grep angie

    angie: master process v1.6.0 #1 [angie]
    angie: worker process #1

After a successful configuration reload (regardless of actual changes), Angie increments the number for processes that received the new config:

sudo angie -s reload
ps aux | grep angie

    angie: master process v1.6.0 #2 [angie]
    angie: worker process #2

If any worker processes from the previous generations continue operation, they become immediately visible:

ps aux | grep angie

    angie: worker process #1
    angie: worker process #2

Note

Don’t confuse the configuration generation number for some sort of a ‘process number’; Angie doesn’t use continuous process numbering for any practical purposes.

Rotating Log-files

In order to rotate log files, they need to be renamed first. After that USR1 signal should be sent to the master process. The master process will then re-open all currently open log files and assign them an unprivileged user under which the worker processes are running, as an owner. After successful re-opening, the master process closes all open files and sends the message to worker process to ask them to re-open files. Worker processes also open new files and close old files right away. As a result, old files are almost immediately available for post processing, such as compression.

Upgrading Executable on the Fly

In order to upgrade the server executable, the new executable file should be put in place of an old file first. After that USR2 signal should be sent to the master process. The master process first renames its file with the process ID to a new file with the .oldbin suffix, e.g. /usr/local/angie/logs/anige.pid.oldbin, then starts a new executable file that in turn starts new worker processes.

It should be noted that the old master process does not close its listen sockets, and it can be managed to start its worker processes again if needed. If for some reason the new executable file works unacceptably, one of the following can be done:

• Send the HUP signal to the old master process. The old master process will start new worker processes without re-reading the configuration. After that, all new processes can be shut down gracefully, by sending the QUIT signal to the new master process.

• Send the TERM signal to the new master process. It will then send a message to its worker processes requesting them to exit immediately, and they will all exit almost immediately. (If new processes do not exit for some reason, the KILL signal should be sent to them to force them to exit.) When the new master process exits, the old master process will start new worker processes automatically.

If the new master process exits then the old master process discards the .oldbin suffix from the file name with the process ID.

If upgrade was successful, then the QUIT signal should be sent to the old master process, and only new processes will stay.

Command-Line Parameters

-h, -?	Display help for command-line parameters, then exit.
--build-env	Display auxiliary information about the build environment, then exit.
-c file	Run with an alternative file for configuration instead of the default file.
-e file	Run with an alternative error log file instead of the default file. The special value stderr specifies the standard error output.
-g directives	Run with extra global configuration directives set, for example: angie -g "pid /var/run/angie.pid; worker_processes `sysctl -n hw.ncpu`;".
-m, -M	Display a list of built-in (-m) or built-in and loaded (-M) modules, then exit.
-p prefix	Run with specified prefix path for angie (the directory where the server files will be located; the default is /usr/local/angie/).
-q	Only display error messages if -t or -T is set; otherwise, do nothing.
-s signal	Send a signal to the master process: stop, quit, reopen, reload, and so on.
-t	Test the configuration file, then exit. Angie checks the configuration syntax, recursively including files mentioned in it.
-T	Same as -t, but also output the summary configuration to standard output after recursively including all files mentioned in the configuration.
-v	Display the Angie version, then exit.
-V	Display the Angie version, the compiler version, and the build parameters used, then exit.