Each
release of sendmail offers more and better ways
to handle queue problems. They are mostly implemented as options.
Table 24-7 in Section 24.7.2 lists
all options that affect the queue. Of special interest are the
MaxQueueRunSize,
Timeout.queuereturn, and
Timeout.queuewarn options. Whenever you upgrade to
a new sendmail release, be sure to read the
RELEASE_NOTES for information about new ways to
solve queueing problems.
The queue directory should never be shared among machines. Such
sharing can make detection of orphaned locks impossible. Bugs in
network-locking daemons can lead to race conditions in which neither
of two machines can generate a queue identifier.
In old versions of sendmail it was possible for
an lf file to be left in place even though its
corresponding mail message was not being processed. Such spurious
files prevented the message from ever being delivered unless they
were removed by hand. Spurious lock files could be detected by
watching the syslog(5) file for frequent
locked warnings.
Homespun programs and shell scripts for delivery of local mail can
fail and lose mail by exiting with the wrong value. In the case of a
recoverable error (a full disk, for example) they should exit with
EX_OSERR or EX_TEMPFAIL. Both of these exit values are defined in
<sysexits.h> and cause the message to be
re-queued.
Because sendmail does a
chdir(2) into its queue directory, you should
avoid removing and re-creating that directory while the
sendmail daemon is running. When processing the
queue, sendmail tries to read the queue
directory by doing an opendir(3) of the current
directory. When the queue directory is removed,
sendmail fails that open and
syslog(3)s the following warning:
orderq: cannot open "/usr/spool/mqueue" as ".": No such file or directory
Some very old versions of sendmail had a bug in
handling the queue that could cause a message to be lost when that
message was the last in a queue run to be processed. This, among
other reasons, is good cause to always make sure you are running the
latest version of sendmail.
The sendmail program assumes that only it and
other trusted root programs will place files
into the queue directory. Consequently, it trusts everything it finds
there that is correctly formatted and has the correct ownership and
permissions. The queue directory must be
protected from other users and untrusted programs.
If the queue directory is on a disk mounted separately from
/ and /usr, be certain to
mount that disk before starting the
sendmail daemon. If you reverse these steps, the
sendmail daemon will
chdir(2) into the queue before the mount. One
effect of the reversal is that incoming mail will use a directory
different from that used by outgoing mail. Another effect is that
incoming queued mail will be invisible. Yet another effect is that
the outgoing queue will never be processed by the daemon.
When using multiple queues, it might be possible to
umount a directory while
sendmail is still running, but you should avoid
this temptation. Never mount or
umount queue disks while
sendmail is running. Stop
sendmail first, do your maintenance, then
restart sendmail.
