1 |
Rich Freeman posted on Thu, 18 Feb 2016 07:22:36 -0500 as excerpted: |
2 |
|
3 |
> 4. In the runlevel paradigm you usually think of services running |
4 |
> inside a runlevel (perhaps this isn't strictly true, but most people |
5 |
> think this way, in part because runlevels don't change much). In |
6 |
> systemd this really isn't the case. Services run before targets, or |
7 |
> after them. A target won't be considered running if anything it depends |
8 |
> on isn't running. |
9 |
|
10 |
Some minor additional notes, with the first one being here. |
11 |
|
12 |
Systemd target units are analogous to edge-triggered interrupts, which |
13 |
they resemble in that they are simply "synchronization points" (the term |
14 |
used in the systemd.target (5) manpage itself). Level-triggered |
15 |
interrupts can be held on or held off (high or low), but edge-triggered a |
16 |
re simply events that occur and then are passed as time moves on. As |
17 |
such, targets can be started, but not normally (while the job queue is |
18 |
idle) stopped, as they de-assert as soon as they are actually reached, |
19 |
tho many of their requirements generally continue to run until stopped by |
20 |
some other event, often conflicts= against some other target or general |
21 |
unit being started, or specific admin systemctl stop. |
22 |
|
23 |
Tho the systemd FAQ suggests this wasn't always so, as it suggests using |
24 |
systemctl list-units --type=target in answer to a question about how to |
25 |
find what "runlevel" you're in. That command seems to return nothing, |
26 |
here, tho, at least while no target is actively starting, so it would |
27 |
seem that answer's a bit dated. |
28 |
|
29 |
It can be noted, however, that certain units, most often specific targets |
30 |
intended to be specifically invokable by users, can be "isolated", as |
31 |
they have the AllowIsolate unit setting. Systemctl isolate <unit> will |
32 |
then cause it to be started exclusively, stopping anything that's not a |
33 |
dependency of that unit. The systemctl emergency, rescue, reboot, |
34 |
shutdown, etc, commands, then become effectively shortcuts to the longer |
35 |
systemctl isolate <named-target-unit> command form. |
36 |
|
37 |
> 5. I'd have to check, but I wouldn't be surprised if systemd doesn't |
38 |
> actually require specifying a target at all. Your default "runlevel" |
39 |
> could be apache2.service, which means the system would boot and launch |
40 |
> everything necessary to get apache working, and it probably wouldn't |
41 |
> even spawn a getty. This is NOT analogous to just putting only apache2 |
42 |
> in /etc/runlevels/default, because in that example openrc is running the |
43 |
> default runlevel, and it only pulls in apache2. Systemd is purely |
44 |
> dependency driven and when you tell it to make graphical.target the |
45 |
> default runlevel it is like running emerge kde-meta. If all you wanted |
46 |
> was kde-runtime you wouldn't redefine kde-meta to pull in only |
47 |
> kde-runtime, you'd just run emerge kde-runtime. Again, I haven't tested |
48 |
> this, but I'd be shocked if it didn't work. Of course, specifying a |
49 |
> service as a default instead of a target is very limiting, but it would |
50 |
> probably work. Heck, you could probably specify a mount as the default |
51 |
> and the system would just boot and mount something and sit there. Or |
52 |
> you could make it a socket and all it would do is sit and listen for a |
53 |
> connection inetd-style. |
54 |
|
55 |
As mentioned both in the systemd FAQ and in the systemd.special (7) |
56 |
manpage, under default.target, this is the default unit started at |
57 |
bootup. Normally, it'll be a symlink to either multi-user.target |
58 |
(analogous to sysvinit semi-standard runlevel 3, CLI, no X), or |
59 |
graphical.target (analogous to sysvinit semi-standard runlevel 5, |
60 |
launching X and and a graphical *DM login). |
61 |
|
62 |
I don't see specific documentation of whether symlinking to a non-target |
63 |
unit is allowed, but systemd does have a commandline option --unit=, |
64 |
which is explicitly documented to take a _unit_, default.target being the |
65 |
default, but other non-target units being possible as well. Presumably |
66 |
systemd would examine said unit, looking for DefaultDependencies=no, and |
67 |
if not specifically set, would start the early "system level" targets, |
68 |
before starting the named unit in place of the normal default.target. |
69 |
|
70 |
So it's definitely possible to do via systemd commandline, but I'm not |
71 |
sure if default.target is followed if it doesn't symlink a target unit, |
72 |
or not. I'd guess yes, but have neither seen it specifically documented |
73 |
nor tested it myself, nor read of anyone else actually testing it. |
74 |
|
75 |
> |
76 |
> I find it more helpful to think of targets as just units that don't do |
77 |
> anything. We don't use them in openrc but I suspect it would work out |
78 |
> of the box, and maybe we should even consider doing it in at least some |
79 |
> cases. For example, right now /etc/init.d/samba uses some scripting to |
80 |
> launch both nmbd/smbd and fancy config file parsing to let the users |
81 |
> control which ones launch. You could instead break that into three |
82 |
> files - smbd, nmbd, and samba. The first two would launch one daemon |
83 |
> each, and the samba init.d script wouldn't actually launch anything, but |
84 |
> would just depend on the others. That would be the systemd target |
85 |
> approach. |
86 |
|
87 |
It should work in openrc, yes, because not all functions need filled in. |
88 |
It's quite possible to have openrc initscripts that have only a start or |
89 |
a stop, not both, for instance, and I remember actually creating custom |
90 |
initscripts of that nature, back when I was still on openrc. So without |
91 |
/both/ start and stop, only dependencies, should work too, unless there's |
92 |
a specific error check for that in openrc, and I can't see why there |
93 |
would be. |
94 |
|
95 |
> Apologies if this is a bit off-topic in an openrc discussion, but I |
96 |
> think the concept of virtual services is a potentially powerful one, and |
97 |
> I think that it might be something openrc would actually benefit from |
98 |
> using. |
99 |
|
100 |
=:^) |
101 |
|
102 |
It would certainly simplify things like the named chroot stuff, that |
103 |
being what I'm familiar with from my openrc days, and from the sounds of |
104 |
it based on other posts, apache, too, as you'd then have a virtual |
105 |
service pulling in multiple modular dependencies, instead of a seriously |
106 |
complex hairball of a single service trying to cram in all this |
107 |
additional functionality that really should be in other modules, making |
108 |
things less complex for both maintainers and admin-users. |
109 |
|
110 |
> However, what I will say is until you actually appreciate that systemd |
111 |
> targets are just virtual units then you'll probably find the entire |
112 |
> systemd startup process to be an indecipherable mess. Not groking this |
113 |
> stuff also makes it easy to incorrectly specify dependencies. I'm sure a |
114 |
> few of us running openrc over the years have accidentially stuck a |
115 |
> service in the wrong runlevel and had something break. Well, in systemd |
116 |
> you might have 47 "runlevels" not actually starting in any particular |
117 |
> order so it is much easier to get it wrong if you don't realize how they |
118 |
> work. They aren't strictly sequential, so there isn't always one |
119 |
> "runlevel" that always comes last that you can be lazy and stick |
120 |
> something "in." |
121 |
|
122 |
Umm... for anyone following systemd documentation, including most non- |
123 |
early/late-system service units whether shipped by systemd itself or |
124 |
other system service upstreams or distro maintainers... |
125 |
|
126 |
multi-user.target is roughly equivalent to the standard sysvinit runlevel |
127 |
3 (that being CLI operation and default system services). |
128 |
|
129 |
graphical.target is roughly equivalent to the standard sysvinit runlevel |
130 |
5 (that being X/XDM graphical login). |
131 |
|
132 |
And graphical.target specifically Requires=multi-user.target, thereby |
133 |
pulling in all its dependencies as well. So multi-user.target is the |
134 |
standard "wanted-by/wants" single "runlevel analog" for CLI services and |
135 |
where nearly everything that doesn't have specific reason to be somewhere |
136 |
else ends up, if enabled. |
137 |
|
138 |
But of course, that's not guaranteed, just documented default and the |
139 |
standard nearly all shipped service units use, and individual distros/ |
140 |
sites/installations may well be setup entirely differently, if they have |
141 |
specific reason for it. |
142 |
|
143 |
-- |
144 |
Duncan - List replies preferred. No HTML msgs. |
145 |
"Every nonfree program has a lord, a master -- |
146 |
and if you use the program, he is your master." Richard Stallman |