configs/system-integration/systemd/README.md

   1 # Systemd Unit Examples for Exim
   2
   3 This directory contains several examples for Systemd units to manage an Exim installation.
   4 There is room for improvement, so please share your ideas or setups that are proven to work
   5 in your environment.
   6
   7 All the service units try to protect the system from unintentional
   8 writes to locations outside of Exim's spool, and log directories.  You
   9 may need to override specific settings, we recommend using Systemd's
  10 override mechanism (`systemd edit …`).
  11
  12 The .service units use `ProtectSystem=strict`, which implies a read-only
  13 file system structure. Exim needs write access to the spool directory
  14 (main config option: `spool_directory`), and the log directory (main
  15 config option: `log_file_path`). For improved security you can even set
  16 `NoNewPrivileges`, if you don't do local deliveries.
  17
  18 The provides Systemd units are examples, containing placeholders
  19 `{{…}}`. The [install script](./install) helps substituting them.\1av
  20 The following placeholders are used currently:
  21 - `exim`:
  22 - `spooldir:`
  23 - `logdir`:
  24
  25
  26 ## Daemon
  27
  28 This is best suited for *average to high traffic systems*, it engages
  29 all built-in Exim facilities, as queue runner management and system load
  30 depending message processing.
  31
  32 The [systemd service unit](./daemon/exim.service) starts the Exim main
  33 process. This process listens on the ports configured in the _runtime
  34 configuration_ (typically `exim.conf`), and supervises all other
  35 activities, including management of queue runner startups. Basically it
  36 calls `exim -odf -q...`.
  37
  38 For regular maintenance tasks (database cleanup) additional units are
  39 [required](./maintenance).
  40
  41 ## Socket
  42
  43 This is best suited for *low traffic* systems, which experience a
  44 message *burst* from time to time. Regular desktop, and edge systems fit this
  45 pattern.
  46
  47 Exim's start is delayed until the first connection. Once a connection is
  48 initiated, Exim starts a listener on the port configured in the [systemd
  49 socket unit](./socket/exim.socket) and waits for more connections. It
  50 exits after being idle for a while. Basically it calls `exim -bw ...`.
  51
  52 Additional [_queue runner_ timer and service units](#queue-runner) are required.
  53
  54 For regular maintenance tasks (database cleanup)
  55 additional units are [required](./maintenance).
  56
  57 ## Inetd
  58
  59 This is best suited for systems with *low traffic*, if the
  60 [socket](#socket) approach doesn't work.
  61
  62 For each incoming connection a new Exim instance starts, handling
  63 exactly this connection and then exits. The listener port is configured
  64 in the [systemd socket unit](./inetd/exim.socket).
  65
  66 Additional [_queue runner_ timer and service units](#queue-runner) are required.
  67
  68 For regular maintenance tasks (database cleanup)
  69 additional units are [required](./maintenance).
  70
  71 ## Queue Runner
  72
  73 This is a *timer*, and a *service* unit which starts Exim queue runner
  74 processes. This is necessary, as the socket activated Exim instances
  75 (from [socket](#socket) and [inetd](#inetd) do not care, once the first
  76 delivery attempt is done.
  77
  78 ## Maintenance
  79
  80 This is a *timer* unit, and a *service* unit for regular maintenance
  81 tasks.  For security it is recommended to use the `User=` Systemd
  82 directive in a local override file.
  83
  84 The service unit cares about tidying Exim's hint databases. It *does
  85 not* rotate the log files, as most systems have their own mechanism for
  86 doing this job (e.g. Logrotate).