$ guides / postfix / postfix-maildrop-queue-growing ▌

Operations Guides

Postfix maildrop queue growing: pickup daemon and local submission failures

Files are accumulating in /var/spool/postfix/maildrop/. Cron output is not arriving in mailboxes. Monitoring alerts that depend on local mail delivery are silently failing. postqueue -p shows normal SMTP traffic flowing, but locally submitted messages are stuck in a directory that should be transient.

The maildrop queue is the only Postfix queue that does not receive mail from the network. It holds messages submitted locally through the sendmail command or the postdrop setgid helper. Every cron job that produces output, every monitoring script that sends mail, and every local application that invokes /usr/sbin/sendmail writes here. The single-threaded pickup daemon drains it within seconds, handing each message to cleanup for header rewriting and content normalization before it enters the incoming queue.

When that drain stalls, the failure is invisible in SMTP logs. There are no status=deferred lines, no connection timeouts, no TLS errors. The mail sits in a spool directory, and standard SMTP monitoring does not cover the local submission path.

What this means

The maildrop queue is normally empty or contains only files that are seconds old. Pickup scans /var/spool/postfix/maildrop/ periodically and is notified by postdrop(1) when a new file arrives. It reads each message, passes it to cleanup(8), and cleanup writes the result into the incoming queue. At that point the message enters normal Postfix mail flow.

If any link in that chain breaks, files accumulate in maildrop.

flowchart LR
    A["cron / script
sendmail CLI"] -->|"postdrop
setgid helper"| B["maildrop/
queue files"]
    B -->|"pickup daemon
single-threaded"| C["cleanup"]
    C -->|"write queue file"| D["incoming/"]
    D -->|"qmgr schedules"| E["active -> delivery"]
    B -.->|"pickup not running"| F["files accumulate"]
    B -.->|"postdrop setgid broken"| G["permission denied"]
    C -.->|"disk or inode full"| H["cannot write incoming/"]

Files older than 10 minutes in maildrop are abnormal. Hundreds or thousands of files, or an oldest file more than a few minutes old, means something in the pickup path is broken.

One nuance: the pickup process may not always be visible in ps output. It is short-lived and spawned by the master process on a timer or when triggered by postdrop. If there is mail sitting in maildrop and pickup is not visible, that is the problem. If maildrop is empty and pickup is not visible, that is normal.

Common causes

Cause	What it looks like	First thing to check
Pickup daemon not running	Files accumulate steadily; no pickup process visible when maildrop is non-empty	`ps aux \| grep pickup` and master.cf service definition
postdrop setgid permission broken	`postdrop` logs “Permission denied” or “mail_queue_enter: create file” errors; common after package updates	`ls -la /usr/sbin/postdrop` and `postfix check`
Local generator flooding	Count grows rapidly; many files with similar timestamps from the same sender	`ls -lt /var/spool/postfix/maildrop/ \| head -20`
Queue partition full or inode-exhausted	Pickup runs but cannot create entries in incoming; “queue file write error” in logs	`df -h /var/spool/postfix` and `df -i /var/spool/postfix`

Quick checks

Run these read-only checks to narrow the cause. All are safe on a production system.

# Check maildrop file count and age of oldest file
ls /var/spool/postfix/maildrop/ | wc -l
ls -lt /var/spool/postfix/maildrop/ | tail -1

# Is pickup running? (only meaningful if maildrop is non-empty)
ps aux | grep pickup | grep -v grep

# Check disk space and inodes on the queue partition
df -h /var/spool/postfix
df -i /var/spool/postfix

# Verify postdrop binary permissions and setgid bit
ls -la /usr/sbin/postdrop

# Check master.cf pickup service definition
postconf -M pickup

# Scan for permission or queue-write errors in recent logs
grep -iE 'mail_queue_enter|permission denied|public/pickup|queue file write error' /var/log/mail.log | tail -20

# Run Postfix's own consistency check
postfix check 2>&1

# Verify the master process is running
ps aux | grep 'postfix/master' | grep -v grep

postfix check validates that /usr/sbin/postdrop and /usr/sbin/postqueue are owned by group postdrop and have the setgid bit set. If it reports warnings, permission drift is likely the root cause.

How to diagnose it

Confirm the symptom. Check the maildrop file count and the timestamp of the oldest file. A count above a few hundred or a file older than 10 minutes confirms the problem.
Verify the master process is running. If master is not running, pickup cannot run either. Check ps aux | grep 'postfix/master' and the PID file at /var/spool/postfix/pid/master.pid. If master is down, see Postfix master process not running.
Check whether pickup is defined in master.cf. Run postconf -M pickup. The output should show the pickup service entry. Some distributions ship master.cf with the pickup service commented out, which means master never spawns it. If the line is missing or commented, that is the cause.
Check postdrop permissions. Run ls -la /usr/sbin/postdrop. The binary should be owned by root:postdrop with the setgid bit set (permissions rwxr-sr-x). If the setgid bit is missing or the group is wrong, postdrop cannot write to the maildrop directory. This commonly happens after a package update that resets file permissions.
Check disk and inode availability. Run df -h /var/spool/postfix and df -i /var/spool/postfix. If either is exhausted, pickup cannot create queue files in incoming even though it may be running. The maildrop files remain because the handoff to incoming fails. Inode exhaustion produces the same “No space left on device” error as a full disk, so check both.
Identify the local mail generator. If pickup is running and permissions are correct, check whether a local process is flooding the queue. Run ls -lt /var/spool/postfix/maildrop/ | head -20 to see the most recent files. If they arrive at regular intervals (every minute, for example), investigate cron jobs and monitoring scripts.
Check for SELinux or AppArmor denials. On systems with SELinux, postdrop may be denied write access to maildrop even when filesystem permissions are correct. Check /var/log/audit/audit.log or run audit2why to identify denials. These do not appear in mail logs.

Metrics and signals to monitor

Signal	Why it matters	Warning sign
Maildrop file count	Direct indicator of pickup backlog	Sustained count above 1000, or any growth over 5 minutes
Oldest maildrop file age	Pickup is not draining the queue	Any file older than 10 minutes
Pickup process existence	Daemon must be spawned by master to drain maildrop	Process absent while maildrop is non-empty
Queue partition disk space	Full disk prevents creation of incoming queue files	Usage above 90%
Queue partition inode count	Inode exhaustion prevents file creation regardless of free space	Usage above 90%
postdrop error rate in logs	Setgid or permission failures	“Permission denied” or “mail_queue_enter” messages
Local mail submission rate	Identifies flooding from cron or scripts	Sudden spike from a single generator

Fixes

Pickup daemon not running or not defined

If postconf -M pickup returns nothing or the service is commented out in master.cf, uncomment the pickup service line in /etc/postfix/master.cf and reload:

# After fixing master.cf, reload configuration
postfix reload

If master itself is not running, start it. Do not skip diagnosing why it stopped. A stale PID file, a configuration error, or a crash could be the underlying cause.

postdrop setgid permission problems

If postfix check reports permission issues, or if postdrop is missing the setgid bit, restore the correct ownership and permissions. These commands modify system binaries:

# Verify current state before changing anything
ls -la /usr/sbin/postdrop

# Restore ownership and setgid bit
chgrp postdrop /usr/sbin/postdrop
chmod g+s /usr/sbin/postdrop

# Also verify postqueue has the same treatment
chgrp postdrop /usr/sbin/postqueue
chmod g+s /usr/sbin/postqueue

# Verify the maildrop directory permissions
ls -ld /var/spool/postfix/maildrop

Upstream postfix-files declares maildrop mode 730 and public mode 710; Debian-family systems commonly install maildrop with the sticky bit as mode 1730.

The maildrop directory should be writable by the postdrop group but not world-readable. If permissions were reset by a package update or manual chmod, restore them from your distribution’s Postfix package defaults.

Local generator flooding

If a cron job or monitoring script is generating mail faster than pickup can drain it:

Identify the generator by examining the most recent files in maildrop.
Add MAILTO="" to the top of the relevant crontab if the output is not needed.
Redirect output to a log file instead of relying on mail delivery: 0 * * * * /usr/local/bin/script.sh >> /var/log/script.log 2>&1.
If the mail is legitimate but high-volume, submit directly via SMTP to localhost instead of through sendmail or postdrop. The Postfix QSHAPE_README discusses the bottleneck risk of delivering large volumes of mail via the pickup service, which is single-threaded and cannot scale to match SMTP injection rates.

Queue partition full or inode-exhausted

If disk or inodes are exhausted, cleanup cannot write the incoming queue file and the message stays in maildrop:

# Check both space and inodes
df -h /var/spool/postfix
df -i /var/spool/postfix

To free space, clear old messages from other queues. The following command deletes ALL messages from the deferred queue. This is destructive and cannot be undone. Use it only if those messages are disposable:

# WARNING: deletes every message in the deferred queue
postsuper -d ALL deferred

Alternatively, delete individual messages by queue ID with postsuper -d <queue_id>. Freeing inodes can be slow if millions of files have accumulated. In severe cases, the queue filesystem may need to be recreated with a higher inode ratio.

See Postfix active queue saturation for strategies on managing queue depth under sustained load.

SELinux denials

If filesystem permissions are correct but postdrop still cannot write:

# Check for SELinux denials related to postdrop
grep postdrop /var/log/audit/audit.log | audit2why

Create a custom SELinux policy module or adjust the context of the maildrop directory as appropriate for your distribution. SELinux denials do not appear in mail logs, which makes this cause easy to miss.

Prevention

Monitor maildrop file count and oldest file age. This is the most commonly missed Postfix signal. Set an alert for any file older than 10 minutes or a count above 1000.
Monitor inodes separately from disk space. Postfix creates many small files. Inode exhaustion produces “No space left on device” errors that look like disk space problems but are not.
Run postfix check in post-deployment validation. This catches permission drift after package updates before it causes a backlog.
Audit cron jobs and local mail generators. Any cron job without MAILTO="" or output redirection generates a sendmail invocation on every run that produces output.
Verify pickup is enabled in master.cf after every Postfix package upgrade. Some distributions disable it by default.
Alert on maildrop growth rate, not just absolute count. A static count of 200 may be normal for your workload. A count growing by 50 files per minute is a problem regardless of the absolute number.

How Netdata helps

Netdata surfaces maildrop backlog signals before they become a crisis:

Per-second maildrop queue depth and file age show accumulation within minutes rather than when someone notices missing cron output.
Disk space and inode utilization on the queue partition are tracked separately. Correlating inode exhaustion with maildrop growth distinguishes “pickup is broken” from “pickup cannot write to incoming.”
Postfix queue breakdown across all subdirectories (maildrop, incoming, active, deferred) shows whether the problem is isolated to local submission or spreading through the mail pipeline.
Process counts for Postfix daemons confirm whether pickup and master are running without needing to SSH in for the first check.
Filesystem metrics (I/O wait, disk operations, inode usage) help distinguish permission or process problems from storage bottlenecks that prevent queue file creation.