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