tidying
[exim.git] / 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).