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 "Exim utilities") 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 "Exim utilities") 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 its process log. The `exiwhat' script (see chapter "Exim utilities") sends the signal to all Exim processes it can find, having first emptied the process log. 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. Restarting causes its process id to change. 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 "The Exim monitor"), or by obeying "exim -bp" 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.
The options `hold_domains' and `hold_domains_except' allow mail for particular domains to be held on the queue manually. These options are intended as temporary operational measures 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.