-
-
Notifications
You must be signed in to change notification settings - Fork 3
todo proc.8
todo-proc - process todo messages from the queue
todo-proc [ -s] | [-c]-d
todo-proc handles todo messages placed into the outgoing queue by qmail-queue. todo-proc by default looks at /var/indimail/queue for messages. This path can be changed by defining the QUEUEDIR environment variable.
todo-proc addresses a problem known as the silly qmail (queue) problem. This problem is found only on system with high injection rates. qmail with a big local and remote concurrency could deliver a tremendous amount of messages but normally this can not be achieved because qmail-send becomes a bottleneck on those high volumes servers. qmail-send preprocesses all new messages before distributing them for local or remote delivering. In one run qmail-send does one todo run but has the ability to close multiple jobs. Because of this layout qmail-send can not feed all the new available (local/remote) delivery slots and therefor it is not possible to achieve the maximum throughput. This would be a minor problem if one qmail-send run could be done in extreme short time. But because of many file system calls (fsync and (un)link) a todo run is expensive and throttles the throughput. todo-proc solves this by having the todo run done by itself rather than by qmail-send This reduces the run time in qmail-send.
todo-proc prepares incoming messages for local and remote deliveries (by creating info/<messid> local/<messid> and remote/<messid> and removing todo/<messid> See also INTERNALS). Next todo-proc transmits the <messid> to qmail-send which will add this message into the priority queue which schedules the message for delivery. todo-proc can be optimized further by making it to transmit the <messids> in chunks rather than every time a file is found in todo directory. The chunk size can be set by defining TODO_CHUNK_SIZE. odo-proc will wait for CHUNK_WAIT seconds (set by environment variable CHUNK_WAIT) before transmitting accumulated all <messids> to qmail-send.
todo-proc can work in two modes - static queue mode or dynamic queue mode. The dynamic queue mode is enabled when passed the -d argument by qscheduler(8).
In dynamic queue mode, todo-proc wakes up on a message from qmail-queue(8). If the environment variable DYNAMIC_QUEUE is set, qmail-queue(8) uses message queue /qmail-queue. If there is any failure using message queues, qmail-queue(8) reverts back to using QUEUE/lock/trigger. When in dynamic queue mode, todo-proc(8) will also respond to qmail-queue running in static mode whhere communications happens through QUEUE/lock/trigger. Here QUEUE refers to the base path of the queue. e.g. /var/indimail/queue/queue1.
In static queue mode, todo-proc normally does a queue run for every injected message and then transmits the <messid> to qmail-send which schedules it for local/remote delivery. If we get too many injections the queue runs will stall scheduling of local/remote deliveries. Usually we see a sharp drop in concurrent deliveries while new messages arrive at high rate in the queue. In such a situation it doesn't make sense to process the queue after each and every injection. It is more important to fill the delivery slots with work to drain the queue. The todo run can be adjusted by setting the environment variable TODO_INTERVAL to have only one queue run every TODO_INTERVAL seconds. It remembers the last complete queue run and will just return if we get triggered before last queue run plus TODO_INTERVAL seconds. If we get triggered before TODO_INTERVAL seconds it will schedule a forced queue run at last complete queue run plus TODO_INTERVAL seconds to not miss the new additions to the queue. TODO_INTERVAL can also be set in the control file todointerval. The control file takes precedence over the environment variable. If TODO_INTERVAL=0, TODO_INTERVAL="" or a value less than zero, todo-proc silently uses 10 secs as the value for TODO_INTERVAL.
If todo-proc receives a HUP signal, it will reread locals, todointerval, virtualdomains, envnoathost, conf-syncdir, and conf-fsync.
if qmail-send receives USR1 signal, it will instruct todo-proc to stop communicating with qmail-send, but continue to pre-process the todo sub directory. This allows qmail-send to dedicate itself to complete scheduling of delivery jobs for the local and remote queue if any. Once pending delivery jobs are over, qmail-send will instruct todo-proc to start sending new delivery jobs. One can also issue the signal SIGUSR2 to make todo-proc start communicationg with qmail-send. SIGUSR1 should be used if qmail-send is unable to cope with high injection rates. One may issue SIGUSR1 if you want to pre-process the incoming emails but schedule delivery later on receipt of SIGUSR2.
If the environment variable USE_FSYNC is set, then todo-proc writes all data to disk ("flushes") all modified in-core data of (i.e., modified buffer cache pages for) the new message to the disk device (or other permanent storage device) so that all changed information can be retrieved even if the system crashes or is rebooted. This includes writing through or flushing a disk cache if present. The call blocks until the device reports that the transfer has completed. This is done for the info and mess files. This can also be set by using conf-fsync control file.
If the environment variable USE_SYNCDIR is enabled, qmail-send forces BSD style directory syncing. This can also be set by using conf-syncdir control file.
todo-proc can be configured to use a queue with a different split subdirectory value than compile time value of 151. This can be done by setting the CONFSPLIT envrionment variable. Additionally, it can process a queue created with todo, intd with subdirectory split instead of without any split. This can be done by setting the BIGTODO environment variable.
The control files conf-syncdir, conf-fsync take precedence over the environment variable counterparts. If the control conf-fsync, conf-syncdir are present, qmail-send will additionally set or unset the environment variables USE_FSYNC, USE_SYNCDIR. This feature is exploited by qmail-local(8). The fsync(2) system call is used for doing this.
todo-proc runs as user qmails, group qmail.
-s
This implies todo-proc will use static queue mode described
previously.
-d
This implements dynamic queue mode described previously. See
multi-queue(7) for a complete overview.
-c
When using dynamic queue mode, this enables compatability mode with the
traditional method of using the lock/trigger fifo in the queue
directory. This allows qmail-queue running in non-dynamic mode to
trigger scan of the todo directory. This method can be used when the
system has qmail-queue clients from qmail or netqmail on the system.
Using compatability mode doesn't give you the full performance benefits
when system is configured to use POSIX IPC for dynamic queues.
Communication between qmail-send and todo-proc
todo-proc -> qmail-send D[LRB]<mesgid>\0 Start delivery for new message with id <messid>. the character L, R or B defines the type of delivery, local, remote or both respectively. L<string>\0 Dump string to the logger without adding additional \n or similar.
qmail-send -> todo-proc H Got a SIGHUP reread /etc/indimail/control/locals and /etc/indimail/control/virtualdomains X Quit ASAP.
todo-proc sends "\0" terminated messages whereas qmail-send sends just one character to todo-proc.
todo-proc borrows its basic design from the ext-todo patch by Claudio Jeker <jeker@n-r-g.com> and Andre Oppermann <opi@nrg4u.com> (c) 1998,1999,2000,2001,2002 Internet Business Solutions Ltd.
qmail-queue(8), qmail-start(8), qscheduler(8), multi-queue(7), mq_open(3) qmail-send(8), qmail-lspawn(8), qmail-rspawn(8), fsync(2) svc(8)