Run-Time Control#
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).
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:
|
fast shutdown |
|
graceful shutdown |
|
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 |
|
re-opening log files |
|
upgrading an executable file |
|
graceful shutdown of worker processes |
Individual worker processes can be controlled with signals as well, though it is not required. The supported signals are:
|
fast shutdown |
|
graceful shutdown |
|
re-opening log files |
|
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.5.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.5.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#
|
print help for command-line parameters. |
|
use an alternative configuration file instead of a default 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. |
|
set global configuration directives, for example: |
|
set angie path prefix, i.e. a directory that will keep server files (default value is /usr/local/angie). |
|
suppress non-error messages during configuration testing. |
|
send a signal to the master process. The argument signal can be one of: stop, quit, reopen, reload |
|
test the configuration file: Angie checks the configuration for correct syntax, and then tries to open files referred in the configuration. |
|
same as -t, but additionally dump configuration files to standard output. |
|
print Angie version |
|
print Angie version, compiler version, and configure parameters |