1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
|
<section xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" xml:id="sec-unit-handling">
<title>Unit handling</title>
<para>
To figure out what units need to be
started/stopped/restarted/reloaded, the script first checks the
current state of the system, similar to what
<literal>systemctl list-units</literal> shows. For each of the
units, the script goes through the following checks:
</para>
<itemizedlist>
<listitem>
<para>
Is the unit file still in the new system? If not,
<emphasis role="strong">stop</emphasis> the service unless it
sets <literal>X-StopOnRemoval</literal> in the
<literal>[Unit]</literal> section to <literal>false</literal>.
</para>
</listitem>
<listitem>
<para>
Is it a <literal>.target</literal> unit? If so,
<emphasis role="strong">start</emphasis> it unless it sets
<literal>RefuseManualStart</literal> in the
<literal>[Unit]</literal> section to <literal>true</literal> or
<literal>X-OnlyManualStart</literal> in the
<literal>[Unit]</literal> section to <literal>true</literal>.
Also <emphasis role="strong">stop</emphasis> the unit again
unless it sets <literal>X-StopOnReconfiguration</literal> to
<literal>false</literal>.
</para>
</listitem>
<listitem>
<para>
Are the contents of the unit files different? They are compared
by parsing them and comparing their contents. If they are
different but only <literal>X-Reload-Triggers</literal> in the
<literal>[Unit]</literal> section is changed,
<emphasis role="strong">reload</emphasis> the unit. The NixOS
module system allows setting these triggers with the option
<link linkend="opt-systemd.services">systemd.services.<name>.reloadTriggers</link>.
If the unit files differ in any way, the following actions are
performed:
</para>
<itemizedlist>
<listitem>
<para>
<literal>.path</literal> and <literal>.slice</literal> units
are ignored. There is no need to restart them since changes
in their values are applied by systemd when systemd is
reloaded.
</para>
</listitem>
<listitem>
<para>
<literal>.mount</literal> units are
<emphasis role="strong">reload</emphasis>ed. These mostly
come from the <literal>/etc/fstab</literal> parser.
</para>
</listitem>
<listitem>
<para>
<literal>.socket</literal> units are currently ignored. This
is to be fixed at a later point.
</para>
</listitem>
<listitem>
<para>
The rest of the units (mostly <literal>.service</literal>
units) are then <emphasis role="strong">reload</emphasis>ed
if <literal>X-ReloadIfChanged</literal> in the
<literal>[Service]</literal> section is set to
<literal>true</literal> (exposed via
<link linkend="opt-systemd.services">systemd.services.<name>.reloadIfChanged</link>).
</para>
</listitem>
<listitem>
<para>
If the reload flag is not set, some more flags decide if the
unit is skipped. These flags are
<literal>X-RestartIfChanged</literal> in the
<literal>[Service]</literal> section (exposed via
<link linkend="opt-systemd.services">systemd.services.<name>.restartIfChanged</link>),
<literal>RefuseManualStop</literal> in the
<literal>[Unit]</literal> section, and
<literal>X-OnlyManualStart</literal> in the
<literal>[Unit]</literal> section.
</para>
</listitem>
<listitem>
<para>
The rest of the behavior is decided whether the unit has
<literal>X-StopIfChanged</literal> in the
<literal>[Service]</literal> section set (exposed via
<link linkend="opt-systemd.services">systemd.services.<name>.stopIfChanged</link>).
This is set to <literal>true</literal> by default and must
be explicitly turned off if not wanted. If the flag is
enabled, the unit is
<emphasis role="strong">stop</emphasis>ped and then
<emphasis role="strong">start</emphasis>ed. If not, the unit
is <emphasis role="strong">restart</emphasis>ed. The goal of
the flag is to make sure that the new unit never runs in the
old environment which is still in place before the
activation script is run.
</para>
</listitem>
<listitem>
<para>
The last thing that is taken into account is whether the
unit is a service and socket-activated. Due to a bug, this
is currently only done when
<literal>X-StopIfChanged</literal> is set. If the unit is
socket-activated, the socket is stopped and started, and the
service is stopped and to be started by socket activation.
</para>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
</section>
|