Sendmail Installation and Operation Guide
SMM:08-17
sites with small number of queue entries this might introduce noticable delays. In general, per-
sistent queue runners are only useful for sites with big queues.
2.3.3. Manual Intervention
Under normal conditions the mail queue will be processed transparently. Howev er, you
may find that manual intervention is sometimes necessary. For example, if a major host is down
for a period of time the queue may become clogged. Although sendmail ought to recover grace-
fully when the host comes up, you may find performance unacceptably bad in the meantime. In
that case you want to check the content of the queue and manipulate it as explained in the next
two sections.
2.3.4. Printing the queue
The contents of the queue(s) can be printed using the mailq command (or by specifying
the -bp flag to sendmail):
mailq
This will produce a listing of the queue id's, the size of the message, the date the message
entered the queue, and the sender and recipients. If shared memory support is compiled in, the
flag -bP can be used to print the number of entries in the queue(s), provided a process updates
the data. However, as explained earlier, the output might be slightly wrong, since access to the
shared memory is not locked. For example, ``unknown number of entries'' might be shown.
The internal counters are updated after each queue run to the correct value again.
2.3.5. Forcing the queue
Sendmail should run the queue automatically at intervals. When using multiple queues, a
separate process will by default be created to run each of the queues unless the queue run is ini-
tiated by a user with the verbose flag. The algorithm is to read and sort the queue, and then to
attempt to process all jobs in order. When it attempts to run the job, sendmail first checks to see
if the job is locked. If so, it ignores the job.
There is no attempt to insure that only one queue processor exists at any time, since there
is no guarantee that a job cannot take forever to process (however, sendmail does include heuris-
tics to try to abort jobs that are taking absurd amounts of time; technically, this violates RFC
821, but is blessed by RFC 1123). Due to the locking algorithm, it is impossible for one job to
freeze the entire queue. However, an uncooperative recipient host or a program recipient that
never returns can accumulate many processes in your system. Unfortunately, there is no com-
pletely general way to solve this.
In some cases, you may find that a major host going down for a couple of days may create
a prohibitively large queue. This will result in sendmail spending an inordinate amount of time
sorting the queue. This situation can be fixed by moving the queue to a temporary place and
creating a new queue. The old queue can be run later when the offending host returns to service.
To do this, it is acceptable to move the entire queue directory:
cd /var/spool
mv mqueue omqueue; mkdir mqueue; chmod 0700 mqueue
You should then kill the existing daemon (since it will still be processing in the old queue direc-
tory) and create a new daemon.
To run the old mail queue, issue the following command:
/usr/sbin/sendmail -C /etc/mail/queue.cf -q
The -C flag specifies an alternate configuration file queue.cf which should refer to the moved
queue directory