Controlling Angie PRO#

To run Angie PRO 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 PRO is up and running:

curl localhost:80

Angie PRO 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 PRO 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).

Angie PRO 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 PRO 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 PRO 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.4.1 #1 [angie]
    angie: worker process #1

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

sudo angie -s reload
ps aux | grep angie

    angie: master process v1.4.1 #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 PRO 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

print help for command-line parameters.

-c file

use an alternative configuration file instead of a default file.

-e file

use an alternative error log file to store the log instead of a default file. The special value stderr selects the standard error file.

-g directives

set global configuration directives, for example:
angie -g "pid /var/run/angie.pid; worker_processes `sysctl -n hw.ncpu`;"

-p prefix

set angie path prefix, i.e. a directory that will keep server files (default value is /usr/local/angie).

-q

suppress non-error messages during configuration testing.

-s signal

send a signal to the master process. The argument signal can be one of: stop, quit, reopen, reload

-t

test the configuration file: Angie PRO checks the configuration for correct syntax, and then tries to open files referred in the configuration.

-T

same as -t, but additionally dump configuration files to standard output.

-v

print Angie PRO version

-V

print Angie PRO version, compiler version, and configure parameters