1# Unit handling {#sec-unit-handling}
2
3To figure out what units need to be started/stopped/restarted/reloaded, the
4script first checks the current state of the system, similar to what `systemctl
5list-units` shows. For each of the units, the script goes through the following
6checks:
7
8- Is the unit file still in the new system? If not, **stop** the service unless
9 it sets `X-StopOnRemoval` in the `[Unit]` section to `false`.
10
11- Is it a `.target` unit? If so, **start** it unless it sets
12 `RefuseManualStart` in the `[Unit]` section to `true` or `X-OnlyManualStart`
13 in the `[Unit]` section to `true`. Also **stop** the unit again unless it
14 sets `X-StopOnReconfiguration` to `false`.
15
16- Are the contents of the unit files different? They are compared by parsing
17 them and comparing their contents. If they are different but only
18 `X-Reload-Triggers` in the `[Unit]` section is changed, **reload** the unit.
19 The NixOS module system allows setting these triggers with the option
20 [systemd.services.\<name\>.reloadTriggers](#opt-systemd.services). There are
21 some additional keys in the `[Unit]` section that are ignored as well. If the
22 unit files differ in any way, the following actions are performed:
23
24 - `.path` and `.slice` units are ignored. There is no need to restart them
25 since changes in their values are applied by systemd when systemd is
26 reloaded.
27
28 - `.mount` units are **reload**ed. These mostly come from the `/etc/fstab`
29 parser.
30
31 - `.socket` units are currently ignored. This is to be fixed at a later
32 point.
33
34 - The rest of the units (mostly `.service` units) are then **reload**ed if
35 `X-ReloadIfChanged` in the `[Service]` section is set to `true` (exposed
36 via [systemd.services.\<name\>.reloadIfChanged](#opt-systemd.services)).
37 A little exception is done for units that were deactivated in the meantime,
38 for example because they require a unit that got stopped before. These
39 are **start**ed instead of reloaded.
40
41 - If the reload flag is not set, some more flags decide if the unit is
42 skipped. These flags are `X-RestartIfChanged` in the `[Service]` section
43 (exposed via
44 [systemd.services.\<name\>.restartIfChanged](#opt-systemd.services)),
45 `RefuseManualStop` in the `[Unit]` section, and `X-OnlyManualStart` in the
46 `[Unit]` section.
47
48 - Further behavior depends on the unit having `X-StopIfChanged` in the
49 `[Service]` section set to `true` (exposed via
50 [systemd.services.\<name\>.stopIfChanged](#opt-systemd.services)). This is
51 set to `true` by default and must be explicitly turned off if not wanted.
52 If the flag is enabled, the unit is **stop**ped and then **start**ed. If
53 not, the unit is **restart**ed. The goal of the flag is to make sure that
54 the new unit never runs in the old environment which is still in place
55 before the activation script is run. This behavior is different when the
56 service is socket-activated, as outlined in the following steps.
57
58 - The last thing that is taken into account is whether the unit is a service
59 and socket-activated. If `X-StopIfChanged` is **not** set, the service
60 is **restart**ed with the others. If it is set, both the service and the
61 socket are **stop**ped and the socket is **start**ed, leaving socket
62 activation to start the service when it's needed.