As was stated previously, Sendmail queue's all messages as a safety net. If for some reason you want to disable this feature, use define(`confSAFE_QUEUE',`False').


To speed up mail processing you could also use multiple disks to help spread the load around. If you have a very large volume of mail to send, it may help to add more disk spindles to help handle the load.


Let's see how to set this up:


/dev/dsk/c0t0d0s0  mounts as /
/dev/dsk/c0t0d0s1  mounts as /var/mail
                   under /var/mail is a directory and subdirectory
                   called queue/q.1
/dev/dsk/c0t0d1s0  mounts as /var/mail/queue/q.2
/dev/dsk/c1t0d0s0  mounts as /var/mail/queue/q.3


Then to have Sendmail use all of these spindles, use:


define(`QUEUE_DIR',`/var/mail/queue/q.*')


Sendmail should run the queue automatically at intervals. When using multiple queues, a separate process will be created to run each of the queues unless the queue run is initiated by a user with the verbose flag.


Sendmail uses the following algorithm to process the queue:


The algorithm is to read and sort the queue, and then attempt to process all jobs in order.


If you're running a large e-mail environment what happens when Sendmail goes offline for some unknown reason? The biggest thing that will happen is your mail queue will grow larger if people keep attempting to send e-mail.


When you go to restart Sendmail you don't want to start it up in the normal manner.


If you do this Sendmail may cause the system to panic.


What happens is this. Sendmail will spawn a daemon to start resending all the mail. The first thing this daemon will do is to scan the entire queue before it starts to send the mail. While the first daemon is still scanning the queue dir, (read: disk activity), it may spawn another daemon to help the first one get caught up with sending the mail.


The first thing the new daemon will do is to, you guessed it, scan the queue directory to see what's there. Now you have two daemons moving the read heads on your disk drive. What happens if Sendmail starts another daemon or two? More disk activity. Does this help the original daemon get caught up on sending the mail? Nope.


As we all know the more disk I/O the slower things get. It could get so bad your system could slow to a crawl. How do you avoid this situation?


When you restart Sendmail, use /usr/lib/sendmail -qp10m instead of the normal rc startup script.


If you want to see how many messages are sitting in the queue waiting to be processed, use mailq -bP.


After the queue is emptied, or down to a normal level, then you'll want to stop Sendmail and restart it with your normal rc script.


If you're sending mail to a machine that seems to take forever to accept the message, consider lowering the Sendmail timeout to spawn a new daemon to a lower time limit. Instead of the default time limit of -q30m (30 minutes) consider using (-q5m) instead. In this manner, Sendmail will spawn another daemon every 5 minutes instead of every 30 minutes to help handle mail delivery chores. The server that is taking 12 minutes to accept one e-mail message from you won't hold up the whole show if you adjust your timeouts.


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. Due to the locking algorithm, it is impossible for one job to freeze the entire queue. However, an uncooperative recipient, host, or a program that never returns can accumulate many processes on your system.


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 using the method mentioned above or 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:


How to Move the Mail Queue, /var/spool/mqueue


If you are moving the mail queue, follow these instructions.


1. Become root on the mail host or assume an equivalent role.


2. Kill the sendmail daemon.


# svcadm disable network/smtp:sendmail


Now sendmail is no longer processing the queue directory.


3. Change to the /var/spool directory.


# cd /var/spool


4. Move the directory, mqueue, and all its contents to the omqueue directory. Then create a new empty directory that is named mqueue.


# mv mqueue omqueue; mkdir mqueue


5. Set the permissions of the directory to read/write/execute by owner, and read/execute by group. Also, set the owner and group to daemon.


# chmod 750 mqueue; chown root:bin mqueue


6. Start sendmail.


# svcadm enable network/smtp:sendmail


How to Run the Old Mail Queue, /var/spool/omqueue


To run an old mail queue, follow these instructions.


1. Become root or assume an equivalent role.


2. Run the old mail queue.


# /usr/lib/sendmail -oQ/var/spool/omqueue -q


The -oQ flag specifies an alternate queue directory. The -q flag says to run every job in the queue. Use the -v flag if you want the output displayed onto the screen.


3. Remove the empty directory.


# rmdir /var/spool/omqueue


The amount of time between forking a process to run through the queue is defined by the -q flag. If you run with delivery mode set to i or b this can be relatively large, since it will only be relevant when a host that was down comes back up. If you run in q mode it should be relatively short, since it defines the maximum amount of time that a message may sit in the queue. (See the MinQueueAge option.)


In some cases you may find that the queue has gotten clogged for some reason. You can force a queue run using the -q flag (with no value). You can add the -v flag (verbose) to watch what happens:


/usr/sbin/sendmail -q -v


You can also limit the jobs to those with a particular queue identifier, recipient, sender, or queue group using one of the queue modifiers. For example, "-qRberkeley" restricts the queue run to jobs that have the string "berkeley" somewhere in one of the recipient addresses. Similarly, "-qSstring" limits the run to particular senders, "-qIstring" limits it to particular queue identifiers, and "-qGstring" limits it to a particular queue group. The named queue group will be run even if it is set to have 0 runners.


You may also place an ! before the I or R or S to indicate that jobs are limited to not including a particular queue identifier, recipient or sender. For example, "-q!Rseattle" limits the queue run to jobs that do not have the string "seattle" somewhere in one of the recipient addresses. Should you need to terminate the queue jobs currently active then sending a SIGTERM to the parent of the process (or processes) will cleanly stop the jobs.


In addition to the option QueueDirectory, queue groups can be declared that define a group of queue directories under a common name. Queue groups are used when your want to have a separate queue that has different characteristics than the default /var/spool/mqueue directory. The syntax for queue groups is as follows:


Qname field=value


where name is the symbolic name of the queue group under which it can be referenced in various places and the "field=name" pairs define attributes of the queue group.


Fields are:


Flags - Flags for this queue group. Currently there is only one flag - f. Which tells Sendmail to fork multiple times to process the queue in parallel.


Nice - The nice increment for the queue group. This value must be greater than or equal to zero.


Interval - The time between two queue runs.


Path - The queue directory of the group (required).


Runners - The number of parallel runners processing the queue. Note that F=f must be set if this value is greater than one.


Jobs - The maximum number of jobs (messages delivered) per queue run.


recipients - The maximum number of recipients per envelope. Envelopes with more than this number of recipients will be split into multiple envelopes in the same queue directory. The default value 0 means no limit.


Only the first character of the field name is checked.


By default, a queue group named mqueue is defined that uses the value of the QueueDirectory option as its path. All paths that are used for queue groups must be subdirectories of QueueDirectory.


Since they can be symbolic links, this isn't a real restriction, If QueueDirectory uses a wildcard, then the directory one level up is considered the 'base' directory upon which all other queue directories must share. Please make sure that the queue directories do not overlap. Do not specify:


O QueueDirectory=/var/spool/mqueue/*
Qone, P=/var/spool/mqueue/dir1
Qtwo, P=/var/spool/mqueue/dir2


because this also includes "dir1" and "dir2" in the default queue group. However,


O QueueDirectory=/var/spool/mqueue/main*
Qone, P=/var/spool/mqueue/dir
Qtwo, P=/var/spool/mqueue/other*


is a valid queue group specification. Options listed in the 'Flags' field can be used to modify the behavior of a queue group. The 'f' flag must be set if multiple queue runners are supposed to work on the entries in a queue group. Otherwise Sendmail will work on the entries strictly sequentially.


The 'Interval' field sets the time between queue runs. If no queue group specific interval is set, then the parameter of the -q option from the command line is used.


To control the overall number of concurrently active queue runners the option MaxQueueChildren can be set. This limits the number of processes used for running the queues to MaxQueueChildren, though at any one time fewer processes may be active as a result of queue options, completed queue runs, system load, etc.


The maximum number of queue runners for an individual queue group can be controlled via the Runners option. If set to 0, entries in the queue will not be processed, which is useful to 'quarantine' queue files. The number of runners per queue group may also be set with the option MaxRunnersPerQueue, which applies to queue groups that have no individual limit. That is, the default value for Runners is MaxRunnersPerQueue if set, otherwise it defaults to 1.


The field 'Jobs' describes the maximum number of jobs (messages delivered) per queue run, which is the queue group specific value of MaxQueueRunSize.


Queue groups should be declared after all queue related options have been set because queue groups take their defaults from those options. If an option is set after a queue group declaration, the values of options in the queue group are set to the defaults of Sendmail unless explicitly set in their declaration.


To select which queue to use you add entries to the access database.


QGRP:Address        Queue_Group_To_Use


Sendmail will then place outgoing mail for the selected address in the appropriate queue.


When an outbound message is stored in the queue it is split into separate pieces. Each piece is stored as a separate file. Files stored in the queue directory are identified by the first two letters of the filename - only the first two letters are different, the rest of the file name for each message is the same.


The first two letters could be:


df - message body
qf - headers
tf - temporary qf rewrite image
xf - transcript file


Always remember:


Sendmail renames a qf file to Qf if there is a severe (configuration) problem that cannot be solved without human intervention. Search the logfile for the queue file id to figure out what happened. After you resolved the problem, you can rename the Qf file to qf and send it again.


df files contain the message body and care should be taken to ensure that no one can read these files.


qf files contain the header information for a message. That is used to:


Delivery the message
Order the messages by priority
Expire the message
Explain the message


If Sendmail cannot deliver the message for some reason, it copies the qf file to a tf file adds error messages to the tf file, and then renames the tf file back to a qf file.


Transcript files are created when you send a message to multiple recipients. If Sendmail cannot deliver the message to some of the recipients, it collects all of the error messages and stores them in an xf file.


Sendmail then sends all the collected error messages back to the sender. If there are no error messages, this file is just deleted.


You can create qf, df, or xf subdirectories under the /var/spool/mqueue directory if you want to. You can also do the same for queue groups.


If shared memory support is compiled in, sendmail stores the available diskspace in a shared memory segment to make the values readily available to all children without incurring system overhead. In this case, only the daemon updates the data; i.e., the sendmail daemon creates the shared memory segment and deletes it if it is terminated. To use this, sendmail must have been compiled with support for shared memory (-DSM_CONF_SHM) and the option SharedMemoryKey must be set. Notice: do not use the same key for sendmail invocations with different queue directories or different queue group declarations. Access to shared memory is not controlled by locks, i.e., there is a race condition when data in the shared memory is updated. However, since operation of sendmail does not rely on the data in the shared memory, this does not negatively influence the behavior.


Quarantined Queue Items


It is possible to "quarantine" mail messages, otherwise known as envelopes. Envelopes (queue files) are stored but not considered for delivery or display unless the "quarantine" state of the envelope is undone or delivery or display of quarantined items is requested. Quarantined messages are tagged by using a different name for the queue file, 'hf' instead of 'qf', and by adding the quarantine reason to the queue file.


Delivery or display of quarantined items can be requested using the -qQ flag to sendmail or mailq. Additionally, messages already in the queue can be quarantined or unquarantined using the new -Q flag to sendmail. For example,


sendmail -Qreason -q[!][I|R|S][matchstring]


Quarantines the normal queue items matching the criteria specified by the -q[!][I|R|S][matchstring] using the reason given on the -Q flag. Likewise,


sendmail -qQ -Q[reason] -q[!][I|R|S|Q][matchstring]


Change the quarantine reason for the quarantined items matching the criteria specified by the -q[!][I|R|S|Q][matchstring] using the reason given on the -Q flag. If there is no reason, unquarantine the matching items and make them normal queue items. Note that the -qQ flag tells sendmail to operate on quarantined items instead of normal items.


Next Section: Troubleshooting - 20 of 32



This Web Site Copyright © 1997 - 2008
by Alan Pae - All Rights Reserved