The master(8) daemon is the resident process that runs Postfix
daemons on demand: daemons to send or receive messages via the
network, daemons to deliver mail locally, etc. These daemons are
created on demand up to a configurable maximum number per service.
Postfix daemons terminate voluntarily, either after being idle for
a configurable amount of time, or after having serviced a
configurable number of requests. Exceptions to this rule are the
resident queue manager, address verification server, and the TLS
session cache and pseudo-random number server.
The behavior of the master(8) daemon is controlled by the
master.cf configuration file, as described in master(5).
Options:
-
- -c config_dir
-
Read the main.cf and master.cf configuration files in
the named directory instead of the default configuration directory.
This also overrides the configuration files for other Postfix
daemon processes.
-
- -D
-
After initialization, run a debugger on the master process. The
debugging command is specified with the debugger_command in
the main.cf global configuration file.
-
- -d
-
Do not redirect stdin, stdout or stderr to /dev/null, and
do not discard the controlling terminal. This must be used
for debugging only.
-
- -e exit_time
-
Terminate the master process after exit_time seconds. Child
processes terminate at their convenience.
-
- -t
-
Test mode. Return a zero exit status when the master.pid lock
file does not exist or when that file is not locked. This is evidence
that the master(8) daemon is not running.
-
- -v
-
Enable verbose logging for debugging purposes. This option
is passed on to child processes. Multiple -v options
make the software increasingly verbose.
Signals:
-
- SIGHUP
-
Upon receipt of a HUP signal (e.g., after "postfix reload"),
the master process re-reads its configuration files. If a service has
been removed from the master.cf file, its running processes
are terminated immediately.
Otherwise, running processes are allowed to terminate as soon
as is convenient, so that changes in configuration settings
affect only new service requests.
-
- SIGTERM
-
Upon receipt of a TERM signal (e.g., after "postfix abort"),
the master process passes the signal on to its child processes and
terminates.
This is useful for an emergency shutdown. Normally one would
terminate only the master ("postfix stop") and allow running
processes to finish what they are doing.