$ guides / postfix / postfix-process-limit-to-limit ▌

Operations Guides

Postfix process limit reached: smtpd process-limit warnings and connection delays

The warning: service "smtp" (smtpd) has reached its process limit "100": new clients may experience noticeable delays message in your mail log means Postfix has run out of smtpd processes. The master daemon caps concurrent instances of each service at a maxproc value defined in master.cf. For smtpd, that cap defaults to 100, inherited from default_process_limit. When all 100 smtpd processes are busy, new TCP connections on port 25 either queue in the kernel listen backlog or get refused.

This is a warning-level log entry rather than an error, so it may not trip default alerting; monitor for the string explicitly. The first symptom most teams notice is external: clients reporting slow mail delivery, monitoring showing connection timeouts to port 25, or deferred mail piling up because inbound messages are not being accepted.

Processes held at the limit are usually stuck on something slow: a milter that stopped responding, a content_filter running behind, or a reverse DNS lookup timing out against a broken resolver. Each stuck smtpd holds a file descriptor and a process slot. If the underlying cause is a resource leak or a crash loop, the resulting process churn accumulates TIME_WAIT sockets that consume file descriptors and ephemeral ports, further constraining the system.

What this means

The Postfix master daemon is a process supervisor. It reads master.cf to learn which services to run, how many concurrent instances of each to allow (maxproc), and what command to execute for each instance. For the smtpd service on port 25, the default maxproc is - (a dash), which means “inherit default_process_limit”, which defaults to 100.

When the number of active smtpd processes reaches that ceiling, the master logs a “has reached its process limit” warning and stops spawning new ones. Incoming TCP connections on port 25 then depend on the kernel listen backlog. They may complete the TCP handshake and sit waiting for an smtpd to accept them, or they may be rejected if the backlog is full.

Postfix 2.5 introduced automatic stress-adaptive behavior (Postfix 2.6 enabled the stress-dependent defaults below by default). When the process limit is reached, the master passes stress=yes to newly spawned smtpd instances, which applies tighter timeouts to shed load quickly:

smtpd_timeout drops from 300s to 10s
smtpd_hard_error_limit drops from 20 to 1
smtpd_per_record_deadline is enabled

smtpd_per_record_deadline remains a distinct parameter (default normal: no, overload: yes); since Postfix 3.7, smtpd_per_request_deadline additionally converts the per-record deadline into a combined per-request deadline under overload.

This helps shed abusive or slow clients faster, but it does not address the underlying cause. If smtpd processes are stuck on a slow milter or DNS lookup, stress mode may not free them in time.

A second concern is TIME_WAIT accumulation. Each smtpd process that exits leaves its TCP socket in TIME_WAIT. With rapid process churn from crashing or short-lived connections, TIME_WAIT sockets can pile up and consume file descriptors or ephemeral ports, effectively lowering the number of usable smtpd slots below the configured maxproc.

flowchart TD
    A[Client connects on port 25] --> B[master spawns smtpd process]
    B --> C{smtpd blocks on}
    C -->|Slow milter| D[Process held until milter timeout]
    C -->|Slow content_filter| E[Process held waiting for filter]
    C -->|DNS reverse lookup| F[Process held on resolver timeout]
    D --> G[smtpd count climbs toward 100]
    E --> G
    F --> G
    G --> H[has reached its process limit warning logged]
    H --> I[Stress mode activates]
    I --> J[New connections queue or refused]
    J --> K[TIME_WAIT sockets accumulate]
    K --> G

Common causes

Cause	What it looks like	First thing to check
Slow or hung milter	smtpd processes stuck in the same state for minutes; milter logs show errors or silence	Milter process health and response time
content_filter backpressure	Incoming queue growing while active queue stays small; filter processes at high count or unresponsive	Filter port connectivity
DNS resolver slowness	Postfix logs show client as “unknown”; all smtpd processes slow, not just some	`dig` from the MTA host against its configured resolver
Connection flood or attack	Many short-lived connections from few IPs; SASL auth failures or relay denies spiking	Per-client connection counts in logs
Policy daemon bottleneck	“connection refused” to policy server after raising smtpd maxproc	master.cf maxproc for policy daemon entries
Crash loop in smtpd	Rapid process turnover; smtpd processes exiting immediately after spawn	mail.log for panic, fatal, or error lines from smtpd

Quick checks

All read-only and safe on a production system.

# Count active smtpd processes
pgrep -c smtpd

# Check default_process_limit (the inherited maxproc for smtpd)
postconf -h default_process_limit

# Show the smtp service definition from master.cf
postconf -M smtp/inet

# Scan recent "has reached its process limit" warnings
grep 'has reached its process limit' /var/log/mail.log | tail -10

# Count established connections on port 25
ss -tn | grep ':25' | wc -l

# Check TIME_WAIT accumulation on port 25
ss -tn state TIME-WAIT | grep ':25' | wc -l

# Check file descriptor usage by postfix processes
for pid in $(pgrep -f postfix); do ls /proc/$pid/fd 2>/dev/null | wc -l; done | paste -sd+ | bc

# Check the actual FD limit the postfix master process inherited
cat /proc/$(head -1 /var/spool/postfix/pid/master.pid)/limits 2>/dev/null | grep 'Max open files'

# Test SMTP greeting latency
time echo QUIT | nc -w 5 localhost 25 | head -1

# Look for smtpd errors indicating crash or resource exhaustion
grep -iE 'smtpd.*(panic|fatal|error)' /var/log/mail.log | tail -20

If your log file is at /var/log/maillog (RHEL/CentOS family) rather than /var/log/mail.log (Debian/Ubuntu family), adjust the grep commands accordingly.

How to diagnose it

Confirm the limit is actually hit. Compare the smtpd process count against maxproc. If pgrep -c smtpd returns a number close to or equal to postconf -h default_process_limit, the limit is being enforced.
Identify what smtpd processes are doing. Use ps -eo pid,stat,wchan,comm | grep smtpd to see wait channels. Processes sleeping with a DNS-related wchan may be stuck on resolver lookups. Processes sleeping on socket reads may be waiting on a milter or content_filter.
Check milter and content_filter health. If you use a milter (opendkim, milter-greylist, rspamd) or a content_filter (Amavis, commercial filter), test its port directly. A milter that takes more than a few seconds to respond will hold smtpd processes for the entire SMTP transaction.
Check DNS resolver latency. Run dig against your configured resolver from the MTA host. If queries take more than a second or fail entirely, slow DNS lookups are likely holding smtpd processes during reverse PTR verification or DNSBL queries.
Examine connection patterns. Use ss -tn | grep ':25' to see current connections. If a small number of client IPs have many connections, you may be under a connection flood. Check postconf -h smtpd_client_connection_count_limit (default 50, half the default process limit) to confirm per-client limiting is active.
Look for rapid process churn. If smtpd processes are spawning and dying quickly, check mail.log for smtpd crash indicators (panic, fatal, segfault). Also check dmesg for OOM kills of smtpd processes.
Check TIME_WAIT pressure. Compare ss -tn state TIME-WAIT | grep ':25' | wc -l against your system’s port range and file descriptor limits. High TIME_WAIT counts with rapid churn indicate a feedback loop where socket exhaustion prevents new smtpd from binding.

Metrics and signals to monitor

Signal	Why it matters	Warning sign
smtpd process count vs maxproc	Direct utilization of the process pool	Sustained count above 80% of maxproc
“has reached its process limit” log frequency	Confirms the limit is being hit repeatedly	Any occurrence; increasing frequency indicates worsening
SMTP greeting latency	Measures actual client impact	Greeting taking more than 2 seconds
TIME_WAIT socket count on port 25	Indicates rapid connection churn consuming resources	Count approaching ephemeral port range limits
Milter/content_filter response time	Slow filters hold smtpd processes	p99 response time above 5 seconds
DNS resolver latency	Slow lookups block smtpd during PTR checks	Lookup time above 1 second
File descriptor usage	Each smtpd, connection, and queue entry consumes FDs	Above 80% of the master process limit
Per-client connection count	Identifies single-source floods	Single client above 50 concurrent connections

Fixes

If smtpd is stuck on a slow milter

The milter is holding smtpd processes for the duration of each SMTP transaction. Check the milter’s own health: process count, memory, and backend database connectivity. If the milter is fundamentally overloaded, either increase its worker count or reduce the time smtpd waits for it.

Set milter timeout parameters (milter_connect_timeout, milter_command_timeout, milter_content_timeout) to values that fail fast rather than letting smtpd hang indefinitely. The defaults are generous and can hold processes for minutes.

Apply with postfix reload.

If the content_filter is slow

Check whether the filter (Amavis, Rspamd, or commercial filter) is keeping up with injection rate. Signs of backpressure: incoming queue growing while active queue stays flat. The filter process count, memory, and its own backend (Redis, ClamAV, database) are the likely culprits.

For immediate relief during an incident, you can temporarily bypass the filter:

# WARNING: This accepts unfiltered mail. Use only as an emergency measure.
postconf -e 'content_filter='
postfix reload

Re-enable filtering as soon as the filter is healthy.

If DNS is slow

Verify /etc/resolv.conf points to a responsive resolver. Test from the MTA host with dig. If the resolver is local (systemd-resolved, nscd, unbound, named), check that process specifically. Adding a fallback resolver to resolv.conf can provide immediate relief. Run postfix reload after changes.

Postfix logs the SMTP client as “unknown” when there is a name service problem. Grep for this pattern to confirm DNS as the cause.

If you need to raise the process limit

Raising maxproc is a valid response when the smtpd pool is genuinely undersized for legitimate traffic, but it must be done deliberately.

Check file descriptor headroom. Each smtpd process consumes multiple FDs (network socket, queue files, milter connections, TLS state). If the FD limit is 1024 and you want 200 smtpd processes, you are likely too tight.
Raise the FD limit first. Use a systemd override or edit /etc/security/limits.conf for the postfix user. Production MTAs commonly need 65536 or higher.
Raise default_process_limit. Note that this affects all Postfix services, not just smtpd:

postconf -e 'default_process_limit=200'

Critical: If you use a policy daemon, set its maxproc to 0 (unlimited) in master.cf. Otherwise smtpd processes will get “connection refused” when connecting to the policy server because there are not enough policy daemon processes to match the new smtpd count.
Apply with postfix reload.

If smtpd processes are crashing

Check mail.log for panic, fatal, or error lines from smtpd. Check dmesg for OOM kills. A crash loop causes rapid process turnover, TIME_WAIT accumulation, and effectively reduces available slots even though the process count fluctuates below maxproc.

If you are running an older Postfix version, check for known crash bugs and update to the latest patch release. smtpd crashes increase process churn and can trigger limit warnings as a secondary effect.

If under a connection flood

If a small number of IPs are opening many connections, verify that smtpd_client_connection_count_limit (default 50) is active. Consider deploying postscreen, which performs pre-queue filtering to block obvious zombies before they reach smtpd. This reduces smtpd process consumption by handling connections that would otherwise occupy smtpd slots during greeting delays.

Prevention

Monitor smtpd process count continuously. Alert when sustained count exceeds 80% of maxproc, not just when “has reached its process limit” appears. The log message is a warning-level entry and can be missed in busy logs.
Monitor milter and filter response times. Do not just check whether the filter process is running. Measure how fast it responds. P99 above 5 seconds will cause smtpd accumulation under load.
Monitor DNS resolver latency independently. Postfix depends on DNS for MX lookups, reverse PTR verification, and DNSBL queries. Resolver slowness manifests as smtpd process pressure.
Set conservative milter timeouts. Default milter timeouts can hold smtpd for minutes. Configure fail-fast timeouts (10-30 seconds) appropriate to your milter’s normal response time.
Raise FD limits proactively. Default ulimits are designed for light workloads, not production MTAs. Set them high enough for your worst-case smtpd count plus headroom.
Deploy postscreen for internet-facing SMTP. It blocks zombies before they consume smtpd processes, reducing the effective load on the process pool.
Track TIME_WAIT counts. Steady growth in TIME_WAIT on port 25 alongside process churn signals crash loops, short-lived connections, or aggressive client retries.

How Netdata helps

Netdata collects per-second metrics and correlates them with mail logs, which shortens the path from the “has reached its process limit” warning to root cause:

Process count vs maxproc in real time. Per-second tracking of smtpd process count against the configured limit, with anomaly detection that flags unusual spawning patterns before the hard limit is hit.
TCP connection state breakdown. Per-second tracking of ESTABLISHED, TIME_WAIT, and other states on port 25 reveals socket churn that reduces available smtpd slots.
File descriptor utilization. System-level FD usage with per-process attribution shows whether FD exhaustion is the hidden constraint behind apparent process limits.
DNS resolver latency. Per-second DNS query timing from the MTA host catches resolver degradation that holds smtpd processes during PTR lookups.
Log correlation. Anomaly detection on mail.log entries, including “has reached its process limit” warnings, smtpd errors, and milter timeouts, correlates process pressure with downstream causes in a single timeline.