Each release of sendmail offers more and better ways to handle
queue problems. They are mostly implemented as options.
Table 34.7 in Section 34.6.2, "The Queue" lists all options
that affect the queue. Of special interest are the new
Whenever you upgrade to a new sendmail release, be sure to
read the RELEASE_NOTES for that latest 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
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 these exit values are defined in <sysexits.h> and cause the message to be requeued.
Because sendmail does a chdir(2) into its queue directory, you should avoid removing and recreating 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
Under a few old versions of sendmail a bug in handling the queue 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. The queue directory must be protected from other users and un-trusted 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 different directory than 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.