Chapter 8: Administration, Optimization, and Monitoring

Chapter 8 delves into basic administration, optimization, and monitoring, doing a good job of covering the first two, while leaving some open questions when it comes to monitoring qmail.

Monitoring qmail involves more than watching logs; it sometimes requires watching and signalling qmail (and related) processes, such as qmail-send and (for daemontools-based installations) readproctitle, and watching and sometimes (carefully) manipulating the qmail queue (or queues).

For example, it might have been helpful to explain how a sysadmin might tackle discovering thousands (or tens of thousands) of messages in the queue, as when users report delivery delays on emails injected into that queue. Sample log output showing exhaustion of remote delivery slots (control/concurrencyremote), actual use of tools such as qmail-qstat, qmail-qread, and qmqtool, as well as whether (or not) to delete (vs. expire) messages and whether and when to restart qmail-send, could have made for a good working example of how to exploit the myriad of smallish tools, in conjunction with Unix concepts such as piping, to flexibly handle a spam or virus outbreak.

Such elaboration, while helpful, would be non-trivial to produce, since it would presumably require a working system demonstrating such problems and their successful mitigation in order to produce real-world examples of tool usage and other interactions, followed by careful obfuscation of actual email addresses and other private information not suitable for publication.

Under "Expanding the qmail-smtpd Log" on Page 119, an example of a /service/qmail-smtpd/run file modified to invoke recordio, especially optionally depending on some easily-changed flag (such as an environment variable settable within /etc/tcp.smtp.cdb or a file) so the qmail-smtpd service needn't be restarted, would have been helpful.

In particular, I was initially confused by the sample /service/qmail-smtpd/log/run file, because I couldn't see how it invoked recordio. Then I remembered that that particular script specified only how and where logging was done (and filtered), not which program(s) (such as recordio) comprise the service that generate the output to be logged.

Under "qmailanalog", in the bullet item on Page 125 describing zsuccesses, I found the note "that many successful deliveries either have no message or have a unique message" confusing, because I couldn't understand how a successful delivery might involve no message. I believe the term "message delivery report" should have been used in this bullet item instead of "message", since it's really the reports, not the messages themselves (or any unique identifications thereof), that are printed by zsuccesses. And it is possible for no message delivery report to accompany an indicator of successful delivery when the recipient has an empty mailbox names — that is, nothing before the "@" in the recipient's email address — because that's how qmail handles such deliveries (by not actually delivering the message anyplace, but recording a successful delivery).

Under "Calculating Your Limits" on Page 127, the concept of the "queue split factor" is described without having previously been suitably introduced, and without appearing in the index. It is touched on again in a bullet item on Page 128, then expanded upon somewhat under "Filesystem", on Page 132. (The queue split factor is set via the conf-split file in the qmail source directory prior to compiling the qmail source code, and defaults to 23.)

More Reviews

Copyright (C) 2007 James Craig Burley, Software Craftsperson
Last modified on 2007-07-10.