You can develop scripts that watch for lines such as these:
Dec 13 10:27:53 your.domain sendmail[642]: grew WorkList for /var/spool/mqueue to
2000
Dec 13 10:29:05 your.domain sendmail[642]: grew WorkList for /var/spool/mqueue to
3000
Dec 13 10:34:31 your.domain sendmail[642]: grew WorkList for /var/spool/mqueue to
4000
... etc., to:
Dec 13 12:40:22 your.domain sendmail[642]: grew WorkList for /var/spool/mqueue to
29000
Dec 13 12:42:50 your.domain sendmail[642]: grew WorkList for /var/spool/mqueue to
30000
Here, the WorkList refers to the number of messages preread so far. By searching for
unusual sizes, you can determine when a queue is about to overfill.
Another technique is to run the mailq command to observe the total number of messages
queued across all queues:
% mailq -OMaxQueueRunSize=0 | tail -1 ?†? V8.7 through V8.11
Total Requests: 34190
% mailq -bP ?†? V8.12 and later
/var/spool/mqueues/q.1/df: entries=34190
Total requests: 34190
For V8.7 through V8.11, the MaxQueueRunSize=0 allows mailq to run swiftly, regardless
of how deep the queue or queues might be. Without that option, and with deep
queues, mailq would be just as slow as the sluggish queue runs, but beginning with
V8.12, the -bP command-line switch does the same thing more quickly.
No matter how you detect the problem, the solution will be the same.
Pages:
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734