This chapter describes some of the regular tasks that need to be done to keep Exim running smoothly.
When certain disasters occur, Exim writes entries to its panic log. These are often copied to the main log as well, but can get lost amid the mass of other entries. The panic log should be empty under normal circumstances. It is therefore a good idea to check it (or to have a cron script check it) regularly, in order to become aware of any problems.
If checking of sender addresses on incoming mail is enabled, the headers of rejected messages are written to the reject log. Other policy rejections also cause entries in this log, which should be regularly inspected to ensure that the checking is working properly, and to pick up errors such as missing DNS entries.
The exicyclog script (see chapter 53) cycles the names of log files, compresses all but the most recent, and deletes the oldest. This should be run at intervals dependent on the amount of mail traffic. For a system with a reasonable amount of mail, running it daily via cron is suggested.
The eximstats script (see chapter 53) produces statistics about messages received and delivered, by analysing log files.
On systems that can restart a system call after receiving a signal, Exim responds to the SIGUSR1 signal by writing a line describing what it is doing to the file exim-process.info in its spool directory. The exiwhat script (see chapter 53) sends the signal to all Exim processes it can find, having first emptied the file. It then waits for one second to allow the Exim processes to react before displaying the results. In order to run exiwhat successfully you have to have sufficient privilege to send the signal to the Exim processes, so it is normally run as root.
When the number of processes handling incoming SMTP calls is limited by setting the smtp_accept_max option, the daemon uses the SIGCHLD signal to detect when any of its subprocesses finishes. On some operating systems this signal sometimes gets lost when the system is very busy. However, Exim's daemon cleans up subprocesses every time it wakes up, so even if SIGCHLD doesn't happen, the completion of subprocesses should eventually get noticed.
A changed configuration file is picked up immediately by any Exim processes that are subsequently started, and by any existing process that re-execs Exim, but it will not be noticed by any existing processes. The daemon process can be caused to restart itself by sending it the SIGHUP signal, which should also be sent when a new version of the Exim binary is installed. SIGHUP causes the daemon to close down, and then re-exec Exim, thus causing it to re-read the configuration file.
The current process id is written to a file whose name depends on the type of daemon being run. By default, the file is written in Exim's spool directory, but a compile-time configuration of PID_FILE_PATH can be used to cause it to be placed elsewhere. When the daemon is both listening for incoming SMTP on the standard port and periodically starting queue runner processes, the file is called exim-daemon.pid. If it is doing only one of these things, the option that started it (either -bd or -q<time>) is added to the file name. It is not necessary to use SIGHUP when changing the contents of any files referred to in the configuration (for example, alias files) since each delivery process reads such files independently.
The queue of messages awaiting delivery can be examined by running the Exim monitor (see chapter 54), or by obeying exim -bp (or its variants) periodically. The exiqsumm utility script can be called to obtain a summary of the waiting messages for each domain, sorted by domain, age, or message count.
If any messages are frozen, their header files and message log files should be examined to determine the cause of the problem. Once the problem is believed to be fixed, the messages can be unfrozen by the administrator, who can also kick off an immediate delivery attempt, and also change recipient and sender addresses if necessary. There are a number of command line options whose names begin with -M for doing these things, and they can also be done from the Exim monitor.
The option hold_domains allows mail for particular domains to be held on the queue manually. This option is intended as a temporary operational measure for delaying the delivery of mail while some problem is being sorted out, or some new configuration tested.
Go to the first, previous, next, last section, table of contents.