1 |
Canek Peláez Valdés posted on Mon, 03 Mar 2014 11:58:18 -0600 as |
2 |
excerpted: |
3 |
|
4 |
> On Mon, Mar 3, 2014 at 11:44 AM, Duncan <1i5t5.duncan@×××.net> wrote: |
5 |
|
6 |
>> Meanwhile, for the record, the systemd and now udev folks have stated |
7 |
>> that they would like to eventually merge udev fully into systemd, and |
8 |
>> indeed, it's already shipped as a single tarball, but that udev is |
9 |
>> likely to remain a separate binary that can be run stand-alone for some |
10 |
>> time, because that's necessary in ordered to be able to keep a somewhat |
11 |
>> small initramfs, with udev but without all the trappings of a |
12 |
>> full-fledged systemd. |
13 |
> |
14 |
> If you use dracut to generate your initramfs, you can get a full-fledged |
15 |
> systemd inside it, so you can use the systemd in the initramfs to start |
16 |
> the systemd in the real filesystem. I use it like that. |
17 |
|
18 |
I had seen hints to that effect, but as I was still running openrc it |
19 |
didn't have any immediate bearing on my dracut and initr* config, beyond |
20 |
USE=-systemd for dracut. |
21 |
|
22 |
>> (This said as an openrc user at least for the time being... even |
23 |
>> apparently one of the only people actually running the live-git |
24 |
>> openrc-9999, or at least all the bugs filed on it seem to be mine. |
25 |
>> I've suspected for some time that I'll eventually switch to systemd, |
26 |
>> but was at least originally hoping to avoid it until it quits actively |
27 |
>> blackholing nearly everything it comes across and had some reasonable |
28 |
>> time to stabilize without gobbling something else up. But when that'll |
29 |
>> be... who knows? And I'm getting an itch to try it one of these days, |
30 |
>> or at least seriously read up on it with a view to _consider_ trying |
31 |
>> it, tho if I do it'll likely still be against my better judgment, since |
32 |
>> I don't see it really stabilizing any time soon and I had originally |
33 |
>> planned to wait for that. So I guess I sort of fall in the middle in |
34 |
>> this debate.) |
35 |
> |
36 |
> If you run OpenRC live, I think you'll be fine running systemd, even |
37 |
> 209/210, which introduced so many changes I've been waiting to upgrade |
38 |
> my systems. |
39 |
> |
40 |
> Come to the dark side. We have cookies. |
41 |
|
42 |
=:^) |
43 |
|
44 |
As you /might/ have deduced by now from the hints of the past-tense "was" |
45 |
and "didn't" above, as well as the fact that I'm dredging up this |
46 |
slightly (10 days) stale thread to reply to... |
47 |
|
48 |
Yeah, I'm actually replying from a systemd booted system, now. |
49 |
|
50 |
As I was privately predicting for myself, but didn't want to promise even |
51 |
to myself[1], I was getting close to the tipping point and this thread, |
52 |
plus a couple extra days off, provided the trigger. |
53 |
|
54 |
Since my experience may be of help to others considering the switch, here |
55 |
we go... |
56 |
|
57 |
In addition to unfortunately not finding a proper good detail but not |
58 |
losing sight of the forest for the trees admin-level-targeted systemd |
59 |
guide, a problem I overcame by simply immersing myself in the idea, full |
60 |
systemd for admins series, multiple hour-ish videos, hours of thinking |
61 |
about it while doing other things, sleeping over what I was learning over |
62 |
several days... |
63 |
|
64 |
There were five specific problems, three of which I've now overcome, with |
65 |
two less pressing ones to go: |
66 |
|
67 |
1) Various fstab mount configuration issues (local-fs.target). |
68 |
|
69 |
To my very pleasant surprise, systemd has a reasonably effective nested- |
70 |
mount-dependency algorithm and can often figure out on its own which |
71 |
fstab configured mount-points are nested under and thus depend on |
72 |
others. This actually simplified things considerably as one of my custom |
73 |
openrc services was basically a localmount that had to come after |
74 |
localmount but before some other service, in ordered to properly handle |
75 |
nested mountpoints, and systemd's nested-mount-dependency processing very |
76 |
nicely solved most of that automatically, without my having to worry |
77 |
about porting a custom service. |
78 |
|
79 |
1a) Unfortunately, systemd's nested-mountpoint detection algorithm isn't |
80 |
smart enough to deal with symlinked paths, at least not in all cases. |
81 |
One of my mount-related problems was thus a bind-mount configured in |
82 |
fstab, that wasn't happening because the origin, on a different non-root |
83 |
filesystem, wasn't mounted yet, so the attempt to bind-mount it elsewhere |
84 |
failed, and local-fs.target was failing as a result of that failure. |
85 |
|
86 |
I solved that one by changing the origin/device path for that fstab entry |
87 |
to point at the canonical path instead of the symlinked path. |
88 |
|
89 |
1b) My fstab entry for tmpfs on /run had a size=2m option, plenty for |
90 |
/run on openrc, but NOT for systemd, as by the time it got to the /run |
91 |
remount it already had an 8-meg early-boot journal file there, so |
92 |
obviously the remount to 2-meg was failing! Of course that was failing |
93 |
local-fs.target as well. |
94 |
|
95 |
That one was hard to track down as I didn't expect systemd to be putting |
96 |
a journal there and thus couldn't imagine what the problem was, but once |
97 |
tracked down, given that I'm running 16-gig RAM, upping that to something |
98 |
a bit more reasonable for the new usage, size=512m, was an easy fix. |
99 |
|
100 |
With those fixes, local-fs.target finally succeeded, and I could get |
101 |
farther in the boot, most services of course having an automatic |
102 |
dependence on local-fs.target. |
103 |
|
104 |
2) Unit file .include deprecated, replaced by *.d/*.conf files. |
105 |
|
106 |
2a) systemd-random-seed.service was failing, again due to a mount-point- |
107 |
detection symlink issue -- my /var is on my rootfs, which is read-only |
108 |
mounted for normal operation (only rw mounted for updates and config |
109 |
changes), so /var/lib/ is a symlink to /home/var/lib, /home naturally |
110 |
being rw mounted in normal operation, and systemd was trying to read the |
111 |
random-seed off that symlinked /home location before it was mounted, |
112 |
because all it knew to check for was /var, which being on / was of course |
113 |
mounted. |
114 |
|
115 |
This one I solved initially by creating a new systemd-random-seed.service |
116 |
file in /etc, .including the default service in /usr/systemd/system/, but |
117 |
with an added RequiresMountsFor= entry. |
118 |
|
119 |
That worked, but later on I found a note in the TODO to document the fact |
120 |
that .include was deprecated and to point people to *.d/*.conf files |
121 |
instead. So I decided to try that. The problem with /that/ was that the |
122 |
TODO reference (and various other *.conf references I found) weren't |
123 |
fully fleshed out, and as a systemd newbie I had some difficulty trying |
124 |
to figure out what they were talking about. |
125 |
|
126 |
But after absorbing systemd for a few days I finally realized that not |
127 |
yet fully documented allusions I was seeing were to (paths like, for this |
128 |
service) /etc/systemd/system/systemd-random-seed.service.d/whatever.conf. |
129 |
And after adding a *.conf file there with the appropriate |
130 |
|
131 |
[Unit] |
132 |
RequiresMountsFor= |
133 |
|
134 |
... entry, I was able to delete my custom service file and return to |
135 |
using the shipped service file, appending the appropriate *.conf line to |
136 |
the shipped configuration that way. |
137 |
|
138 |
2b) I wasn't satisfied with the default gpm unit file config either, but |
139 |
by the time I got to that, I knew .includes were deprecated, and was in |
140 |
the process of trying to figure out what the allusion to *.d/*.conf was |
141 |
all about. |
142 |
|
143 |
But once I figured that out for random-seed, I was quickly able to add |
144 |
/etc/systemd/system/gpm.service.d/execstart.conf , with a customized |
145 |
ExecStart= line. =:^) |
146 |
|
147 |
|
148 |
3) Systemd network config. |
149 |
|
150 |
This one took me awhile too. After the above and a few other minor |
151 |
tweaks to general systemd/journald/logind configuration[2], the big |
152 |
problem was that I was still networkless. I didn't want to install |
153 |
network manager or whatever for a simple single-NIC static IP config, I'm |
154 |
still on systemd-208 as I've not figured out the systemd/dracut thing |
155 |
yet, so I don't have the 209+ networkd yet, and the various static-ip- |
156 |
configuring network.service units I could find via google (plus one on a |
157 |
systemd bug on bugs.g.o) all used ip, from iproute2, which I had never |
158 |
installed as the old ifconfig and route from net-tools had to that point |
159 |
done all I needed it to do. |
160 |
|
161 |
IMO this one's likely the biggest current problem for the gentoo masses |
162 |
who might contemplate a systemd switch, as my other problems are due to |
163 |
my decidedly custom config or are reasonably covered on the wiki.g.o |
164 |
systemd page, while there's very likely quite a few gentooers still on |
165 |
ifconfig/net-tools and unfortunately there's very little network |
166 |
discussion on the wiki page at all, let alone a nice step-by-step in the |
167 |
gentoo documentation tradition, covering ifconfig/net-tools users among |
168 |
others. =:^( |
169 |
|
170 |
I'm actually quite disappointed that the gentoo/systemd folks don't have |
171 |
some sort of virtual/network-manager package or the like setup, with the |
172 |
various network.service and similar files for each one, and good coverage |
173 |
on the wiki. Given all the noise around systemd, and the vital role I'd |
174 |
guess a working network config plays for most gentoo boxes, you'd think |
175 |
that would be well covered. Oh, well... At least it appears now to be a |
176 |
quite temporary problem, to hopefully be solved with the networkd in |
177 |
210/211/whatever-the-next-unmasked/unblocked happens to be. |
178 |
|
179 |
Anyway, a quick emerge --pretend iproute2 said it wasn't going to pull |
180 |
any other deps I didn't already have, and I decided a single additional |
181 |
reasonably core package that I really probably should have installed |
182 |
years ago was after all a pretty small price to pay, so I finally just |
183 |
bit the bullet and installed it, and then setup the network@.service file |
184 |
using the ip command from iproute2. |
185 |
|
186 |
Not so painful after all, but it'll still be nice when I get 210 or 211 |
187 |
or whatever installed, and can hopefully use the new networkd solution |
188 |
instead of the still unofficial custom hack I've installed to deal with |
189 |
networking for the time being. |
190 |
|
191 |
Which brings me up to current, with those three issues behind me. |
192 |
|
193 |
The remaining two issues are: |
194 |
|
195 |
4) Dracut and systemd |
196 |
|
197 |
4a) Dracut's USE=systemd, enable or disable? |
198 |
|
199 |
What does that do and given that the current systemd-less initr* I'm |
200 |
running now works well booting regardless of whether init=systemd, init |
201 |
(openrc), or bash (rescue shell), will whatever changes systemd in the |
202 |
initr* brings be worth it, or not? |
203 |
|
204 |
Of course since you mentioned that you're running with systemd in your |
205 |
init, I'm hoping you can be of help on this one. =:^) |
206 |
|
207 |
4b) The ongoing systemd-209+ file "musical chairs" and the havoc that |
208 |
plays with dracut, thus the current >=systemd-209 blockage in dracut. |
209 |
|
210 |
It'd sure be nice to have this resolved one way or another, particularly |
211 |
so given that 209+ brings the hopefully more final networkd solution to |
212 |
#3 above, as well. I was actually hoping that the multi-device btrfs |
213 |
root kernel command-line rootflags issue was resolved so I could just |
214 |
drop the initr* thing now and thus wouldn't have to worry about dracut |
215 |
any more, but as I posted in the earlier post, unfortunately not. |
216 |
|
217 |
5) A couple remaining minor service failures: |
218 |
|
219 |
5a) ntp.service is still failing, for some reason. |
220 |
|
221 |
While I was running ntp on the old mobo before I upgraded and thus |
222 |
haven't ever really run this one without it, I've no reason to think this |
223 |
machine's hardware is /bad/ at keeping time, so ntp isn't critical. But |
224 |
it'll be nice to find whatever's going on there and fix it. |
225 |
|
226 |
Based on an aside-comment I read when researching something else, I |
227 |
already have one lead to check on this one -- the comment said systemd's |
228 |
privatetmp option doesn't play well with /var/tmp being a symlink to / |
229 |
tmp, and that's what I have here (with /tmp in turn being tmpfs), and I |
230 |
think the ntp unit might use privatetmp, so... But I've yet to confirm, |
231 |
and then I'll have to look for alternatives, so... |
232 |
|
233 |
5b) On openrc, I have a custom user-bootclean service that cleans up a |
234 |
few stray user files at boot, that systemd created an attempted port for, |
235 |
except it's failing. I've not investigated that one at all yet, but just |
236 |
as I write this it occurs to me that the problem might be yet another |
237 |
symlinked path mount-dependency issue, so I now have one lead to |
238 |
investigate on that one, too. |
239 |
|
240 |
5c) bind/named (not failing but reduced functionality) |
241 |
|
242 |
There's a gentoo bug about this as well. Openrc's named/bind initscript |
243 |
has an optional chroot feature. Systemd has both a legacy chroot support |
244 |
feature and a newer kernel-namespaces-based chroot replacement, but the |
245 |
shipped named.service file doesn't make use of either one. If nobody |
246 |
else gets to that bug before I get comfortable enough with systemd to try |
247 |
to address it myself, I'll try to come up with a systemd-style solution, |
248 |
potentially using namespaces, to parallel the gentoo/openrc named |
249 |
initscript's optional chroot feature. |
250 |
|
251 |
https://bugs.gentoo.org/show_bug.cgi?id=496198 |
252 |
|
253 |
|
254 |
Other than that... a couple positives already. =:^) |
255 |
|
256 |
1) As mentioned in problem #1 above, systemd has actually surprisingly |
257 |
good nested mountpoint dependency resolution. My setup is complicated |
258 |
enough I really appreciate that, and now that I'm "dual-booting" openrc |
259 |
and systemd <g>, I definitely miss that feature on openrc! =:^0 |
260 |
|
261 |
2) Speed, WOW! |
262 |
|
263 |
I've had openrc's parallel boot option enabled for years, but systemd |
264 |
really does run circles around it! I'd guess a lot of that's due to the |
265 |
socket-based activation along with the mount dependency resolution such |
266 |
that services that are only dependent on each other due to that can still |
267 |
start in parallel, and particularly with socket-based dependencies, the |
268 |
otherwise depending service can often actually fully initialize if it |
269 |
gets to that point before the depended service is up, as long as the |
270 |
socket is already active and buffering any data the depending service |
271 |
might try to write to it. |
272 |
|
273 |
The fact that it's all C based and mostly declarative, with near-zero |
274 |
scripting and far /far/ less forking, thus short-circuiting a good |
275 |
portion of what even openrc's semi-C-based solution does, certainly helps |
276 |
as well. |
277 |
|
278 |
And of course the fact that I'm on SSD, where all those services starting |
279 |
in parallel doesn't trigger a seek-storm on the spinning rust that's not |
280 |
there to have a seek-storm on, doesn't hurt! (Systemd has a read-ahead |
281 |
service to counteract part of the parallel-init seek-storm issue, but |
282 |
spinning rust will still be a bit of a bottleneck. I had switched to SSD |
283 |
and my boot times improved, but in hindsight on openrc, only to a point, |
284 |
because the service-dependency on openrc then became the bottleneck. |
285 |
With systemd's socket-based-activation and the like killing /that/ |
286 |
bottleneck too, the speed of SSD **REALLY** shows it's stuff! I had no |
287 |
/idea/!) |
288 |
|
289 |
I have a feeling that once I get settled in, I'll be doing far more full |
290 |
shutdowns, since boottimes really /are/ trivial on systemd. And looking |
291 |
to the future, if logind ends up doing for kde5 login times what systemd |
292 |
did for boot times... WOW! The idea of shutdown and startup cycles |
293 |
being so trivial one might as well just shut down when going to microwave |
294 |
a snack, since bootup and session startup's literally mostly the time |
295 |
waiting for the human to type in the password... |
296 |
|
297 |
|
298 |
--- |
299 |
Notes: |
300 |
|
301 |
[1] Predicting but not promising, even to myself: I've discovered that I |
302 |
work best without deadlines or too specific goals, which only tend to |
303 |
demotivate and drive procrastination. Left to itself, at some point the |
304 |
drive to find some stable conclusion normally takes over, at which point |
305 |
it's generally a done deal, concluded far more rapidly and with more |
306 |
finality than it would be, had I tried to artificially drive it myself, |
307 |
or let others try to drive it for me. |
308 |
|
309 |
[2] General configuration changes, well enough documented that I didn't |
310 |
have much problem with them: |
311 |
|
312 |
(a)/etc/systemd/system/default.target symlink pointing at multi-user, |
313 |
since I login at the CLI and have XSESSION set so I can startx, so systemd |
314 |
would quick complaining about the missing *DM service. |
315 |
|
316 |
(b) /etc/systemd/journald.conf: Storage=volatile at least until I figure |
317 |
out whether I want to keep syslog-ng or not, appropriate RuntimeMaxUse |
318 |
and RuntimeKeepFree values, ForwardToConsole=yes and TTYPath=/dev/tty12, |
319 |
so I get the traditional TTY12 console log. |
320 |
|
321 |
(c) Setting NAutoVTs and ReserveVT= in /etc/systemd/logind.conf |
322 |
|
323 |
-- |
324 |
Duncan - List replies preferred. No HTML msgs. |
325 |
"Every nonfree program has a lord, a master -- |
326 |
and if you use the program, he is your master." Richard Stallman |