Postfix master process not running: the whole MTA is down

When the Postfix master process is not running, the entire MTA is down. No mail is received on port 25. No delivery agents are spawned. The queue manager cannot run. Local submissions via sendmail queue up but go nowhere. Upstream senders either timeout, defer, or bounce.

Symptoms are uniform regardless of cause: postqueue -p returns a fatal error, SMTP connections to port 25 are refused, and no master process appears in the process table. The underlying cause varies: OOM kill, stale lock file from an unclean shutdown, port conflict, configuration error, or PID namespace confusion in a container.

Running systemctl restart postfix is the natural reflex, but it can fail silently if the root cause is a stale lock file, a port conflict, or a config error. This guide covers distinguishing a genuinely stopped master from stale-state confusion, finding the root cause, and restoring service without compounding the problem.

What this means

The Postfix master(8) daemon supervises the entire MTA. It reads master.cf for service definitions, holds the process table, and spawns daemons on demand: smtpd for reception, qmgr for queue management, pickup for local submissions, cleanup for message sanitization, smtp for outbound delivery, and local or virtual for mailbox delivery. Master never handles mail directly; it only manages subprocess lifecycles.

Postfix coordinates startup using two files:

• master.pid in the queue directory (typically /var/spool/postfix/pid/master.pid), which stores the master PID
• master.lock in the data directory (typically /var/lib/postfix/master.lock), which serves as an exclusive startup lock

When master starts, it writes master.pid and acquires master.lock. When it stops cleanly, it removes both. An unclean exit from OOM kill, SIGKILL, power loss, or kernel panic can leave these files behind, causing the next startup attempt to see stale state and refuse to proceed.

The critical diagnostic question is not just “is master running” but “what state is the system actually in.” A stale PID file pointing at a recycled PID, a master.lock left behind by a crash, or a container where PID 1 is something other than master can all create misleading signals.

flowchart TD
    A["No mail flowing"] --> B{"master in process table?"}
    B -->|Yes| C{"postqueue -p responds?"}
    C -->|Yes| D["Investigate queues or qmgr"]
    C -->|No| E["qmgr may be hung"]
    B -->|No| F{"master.pid valid?"}
    F -->|Stale PID| G["Stale PID file after crash"]
    F -->|Missing| H["Master genuinely stopped"]
    G --> I["Check logs, ports, config"]
    H --> I
    I --> J["Clear stale state if needed"]
    J --> K["postfix start"]

Common causes

Quick checks

# Check if the master process is running
ps aux | grep '[p]ostfix/master'

# Read the PID file and verify the referenced process
PID=$(cat /var/spool/postfix/pid/master.pid 2>/dev/null)
echo "PID file says: $PID"
ps -p "$PID" -o pid,comm,lstart 2>/dev/null || echo "No such process"

# Test master liveness (exit 0 = running)
postfix status; echo "exit: $?"

# Verify queue manager responsiveness
time postqueue -p >/dev/null 2>&1 && echo "qmgr responsive" || echo "qmgr not responding"

# Check for ownership and permission problems
postfix check 2>&1

# Check listening sockets on SMTP and submission ports
ss -tlnp | grep -E ':25 |:587 '

# Test SMTP greeting (should return 220 with hostname)
echo QUIT | nc -w 5 localhost 25 | head -1

# Check for stale lock file in data directory
ls -la /var/lib/postfix/master.lock 2>/dev/null && echo "master.lock exists" || echo "no master.lock"

# Check kernel logs for OOM or signal kills targeting postfix
dmesg -T 2>/dev/null | grep -iE 'oom|killed.*postfix|postfix.*kill' | tail -20

# Check maillog for fatal or panic messages
# Path varies by distribution: /var/log/mail.log (Debian/Ubuntu) or /var/log/maillog (RHEL/CentOS)
grep -iE 'fatal|panic' /var/log/mail.log /var/log/maillog 2>/dev/null | tail -20

How to diagnose it

1. Confirm the master is actually absent. Run ps aux | grep '[p]ostfix/master'. If a process named master owned by root or postfix exists, the problem may be a hung qmgr or a different issue, not a dead master. Proceed only if no master process exists.

2. Check the PID file. Read /var/spool/postfix/pid/master.pid. If it exists, note the PID and verify it is alive and is actually master: ps -p <PID> -o comm=. If the process is something else (a recycled PID), the PID file is stale. If the file is missing, master either never started or was stopped cleanly.

3. Compare timestamps. Check the PID file modification time: stat /var/spool/postfix/pid/master.pid. Compare against your expected last restart time. If the mtime is hours or days old, the file is almost certainly stale from a crash.

4. Check the lock file. Look for master.lock in the data directory. If it exists and no master process is running, it is stale and will block restart.

5. Review logs for the crash cause. Before restarting, check what killed master:

   • dmesg -T | grep -i oom for memory pressure
   • journalctl -u postfix --since "1 hour ago" for systemd-managed instances
   • grep -iE 'fatal|panic|warning' /var/log/mail.log (or /var/log/maillog on RHEL/CentOS) for Postfix-internal errors

6. Check for port conflicts. If something else is listening on port 25, master will fail to bind and exit immediately: ss -tlnp | grep ':25 '. Common culprits include another Postfix instance, sendmail, or a container port forward.

7. Verify configuration validity. Run postfix check. This catches ownership problems, permission errors, and missing directories. Also check postconf -n for unexpected values after a package update that may have changed defaults.

8. Test the actual startup. Run postfix start and immediately check postfix status. If it fails, read the maillog for the specific error. Do not loop on restart attempts without understanding the failure. Rapid restart loops compound problems through repeated queue scans, DNS hammering, and log flooding.

Metrics and signals to monitor

Fixes

Master crashed from OOM or signal kill

If dmesg shows the OOM killer targeting master or its children, the system is under memory pressure. Restarting Postfix alone will not prevent recurrence.

1. Free immediate memory if needed, then run postfix start.
2. Investigate which process consumed memory. Large message processing, queue backlog, or a misconfigured default_process_limit can cause this.
3. Check postconf | grep process_limit and reduce if the count is too high for available memory.
4. Consider adding swap or increasing instance memory if this recurs.

Stale PID file

If the PID file references a dead or wrong process:

# Confirm no master process is running first
ps aux | grep '[p]ostfix/master'

# Remove the stale PID file
rm /var/spool/postfix/pid/master.pid

# Check for stale master.lock before starting (see next subsection)
postfix start

# Verify
postfix status

Stale master.lock

If postfix start reports the system is already running but no master process exists, the lock file is likely stale:

# Confirm no master process is running
ps aux | grep '[p]ostfix/master'

# If confirmed absent, remove the stale lock
rm /var/lib/postfix/master.lock

# Start master
postfix start

Warning: only remove master.lock when you have confirmed no master process is running. If another instance is legitimately using the lock, removing it can cause two masters to start simultaneously, leading to queue corruption.

Port already in use

If master fails to bind with an address-in-use error:

# Identify what holds the port
ss -tlnp | grep ':25 '

If it is another Postfix instance, stop it first with postfix stop (use -c for the correct instance if multi-instance). If it is sendmail or another MTA, stop that service. If it is a container port forward, adjust your container configuration.

Configuration error

If postfix check or the maillog shows fatal configuration errors:

1. Identify the specific error in the logs.
2. Fix the configuration in main.cf or master.cf.
3. Run postfix check again to confirm.
4. Run postfix start.

Common post-update issues include changed compatibility_level defaults, new TLS requirements, or missing map databases. On systems that have removed Berkeley DB support, Postfix 3.11 and later provides postfix non-bdb to migrate to lmdb or cdb.

Container PID namespace confusion

Inside a container, the master process may run as PID 1, which changes signal handling and process group behavior. Postfix 3.3 and later provides master -i (init mode) for this scenario. Postfix 3.4 and later provides postfix start-fg, which keeps master in the foreground and enables init mode when PID equals 1.

If you are running an older Postfix in a container without init mode, the master may not handle SIGTERM correctly, leading to unclean shutdowns and stale lock files. Either upgrade to 3.4 or later and use postfix start-fg, or use an init wrapper such as tini or dumb-init as PID 1 with master as a child.

Also verify logging. Postfix defaults to syslog, which requires either a syslog daemon inside the container or the host /dev/log socket mounted. Postfix 3.4 and later supports maillog_file = /dev/stdout for direct stdout logging.

Prevention

• Monitor inode usage on the queue filesystem. Inode exhaustion causes cascading failures that can crash the master. Alert below 5 percent free inodes.
• Set appropriate ulimits. The default file descriptor limit (often 1024) is insufficient for production Postfix. Configure systemd overrides or /etc/security/limits.conf for the postfix user.
• Use systemd PIDFile directive carefully. If your unit file specifies PIDFile=, systemd tracks the main process by that PID. A recycled PID pointing at an unrelated process can cause collateral damage on stop.
• Test shutdown and startup procedures regularly. Many teams discover stale lock file problems only during real incidents. Practice postfix stop && sleep 2 && postfix start to confirm clean shutdown works.
• Monitor for crash loops. Multiple “starting.*version” log entries in a short window indicate master is crashing and restarting. Investigate before the queue fills.
• Keep Postfix patched. Security vulnerabilities in SMTP parsing or other mail-handling components can crash smtp and smtpd child processes repeatedly, creating system instability that looks like a master problem.

How Netdata helps

• Process liveness at per-second resolution. Netdata detects the absence of the master process within seconds and correlates it with system-level events like memory pressure or OOM kills.
• Queue depth metrics. The Postfix collector tracks queue sizes across incoming, active, deferred, maildrop, hold, and corrupt. A sudden freeze across all queues signals that master has stopped, even before an external probe fails.
• Disk and inode monitoring. Netdata surfaces inode exhaustion and disk space as separate signals adjacent to process liveness, shortening root cause analysis for common crash triggers.
• Anomaly detection. Netdata ML-based anomaly detection flags unusual patterns in process counts, queue growth rates, and system resource usage that can precede a master crash.
• Correlation across the stack. When the master is down, correlate Postfix process state with DNS resolver health, disk I/O, network connectivity, and memory usage in the same time window.

Related guides

No related troubleshooting guides are available yet. See the Postfix operations hub for the broader monitoring framework, signal taxonomy, and failure pattern catalogue.