1 |
Hi list, |
2 |
|
3 |
(Normally I ask these types of questions to gentoo-user, but thought I'd try |
4 |
here for once, especially given the ease with which systemd flamewars erupt on |
5 |
gentoo-user, compared to the much more civil discussions I've seen here.) |
6 |
|
7 |
So, at night on Saturday, 14th February, I decided, on a whim, to install |
8 |
systemd on my Uni laptop. Everything went well, save for some remaining |
9 |
questions (see below). The Gentoo systemd wiki entry was very helpful. |
10 |
|
11 |
[ It's really strange how that works: I just got the sudden urge to try systemd |
12 |
out, for no real reason at all, and couldn't stop myself. Weird... ] |
13 |
|
14 |
Heh... I was originally going to send this *before* migrating my desktop, but |
15 |
it turns out I liked systemd enough to want to switch my desktop to it before I |
16 |
managed to finish writing this. And holy crap, Duncan was right: systemd is |
17 |
*so* *fast* on an SSD, it's just not funny. It takes *3 seconds* after the |
18 |
kernel boots for me to get a login screen (for a total of about 5-6 seconds |
19 |
after the boot loader). I barely get a chance to see systemd's messages, they |
20 |
just start zipping by, and then *wham*: login screen. I am *amazed*! |
21 |
|
22 |
*ahem* |
23 |
|
24 |
Anyway, I thought it might be interesting to report other things I did and what |
25 |
I like about systemd so far. Due to the length and additional context I'll |
26 |
split the rest of this email into sections for better readability. I apologise |
27 |
for the length; in my defence, this is a fundamental system change, and I |
28 |
wanted to offer enough context for everything. |
29 |
|
30 |
== Additional changes on the laptop == |
31 |
|
32 |
I replaced laptop-mode-tools with tlp from the overlay of the same name (not |
33 |
directly available via layman, but there's a bug on b.g.o that links to the |
34 |
GitHub repo, which has installation instructions). Since I controlled the |
35 |
backlight with lmt, and tlp doesn't support that, I had to find a replacement |
36 |
for that feature. I ultimately decided on power-backlight, which I found via |
37 |
the Arch Linux wiki. I wrote an ebuild and put it in my personal overlay |
38 |
(http://sourceforge.net/p/mjolietoverlay/code/ci/master/tree/app-laptop/power-backlight/), |
39 |
and so far everything is working fine. |
40 |
|
41 |
This might seem like a pointless change, but Arch switched to it, too, and |
42 |
doesn't even package lmt anymore (albeit only since late 2014), so it seems |
43 |
like the way forward. |
44 |
|
45 |
== Additional changes on both systems == |
46 |
|
47 |
I uninstalled acpid, since the Gentoo Wiki page on systemd mentions that it |
48 |
might not be necessary (see the question below). Being able to do this was |
49 |
another reason I switched to tlp, since it doesn't depend on acpid. So far I |
50 |
have yet to notice anything amiss. |
51 |
|
52 |
I also uninstalled tmpwatch, since systemd has a built-in service for doing the |
53 |
same thing (systemd-tmpfiles). |
54 |
|
55 |
== Things I have *not* gotten rid of (yet) == |
56 |
|
57 |
Fcron is still around, mainly because packages might rely on it being there |
58 |
(e.g., man-db and mlocate install files there), but also because I haven't |
59 |
researched systemd timers yet. |
60 |
|
61 |
I plan on uninstalling syslog-ng, but haven't done so yet. I simply feel |
62 |
better waiting a bit, even though I don't run it anymore. Man, I feel silly |
63 |
after typing that... |
64 |
|
65 |
== Network migration on my desktop == |
66 |
|
67 |
My desktop has a somewhat more complicated network setup than the laptop (which |
68 |
uses NetworkManager). The wan0 network device is no problem, but I also have a |
69 |
bridge with one physical device connected to it, and one dummy device. |
70 |
|
71 |
Thus, I had to migrate my netifrc based configuration. Due to word of mouth, I |
72 |
decided on netctl. I originally ignored systemd-networkd because I keep |
73 |
hearing that it's only for simple networks, but after looking at the man page |
74 |
it appears that it can do (almost) everything that I needed it to, although I'm |
75 |
not sure about dummy device support. I need that for MATLAB, which stupidly |
76 |
requires the presence of an interface named eth0, whose MAC address it verifies |
77 |
during its licence check. This became a problem after renaming my network |
78 |
devices following the news entry 2013-03-29-udev-upgrade ("Upgrading udev to |
79 |
version >=200"). |
80 |
|
81 |
What surprised me was that netifrc doesn't seem to integrate dummy devices |
82 |
properly, i.e., it doesn't seem to be possible to rename them in |
83 |
/etc/conf.d/net directly. I implemented that via an appropriate call to ip in |
84 |
an /etc/local.d file, and had "net.eth0" depend on "local". So /etc/conf.d/net |
85 |
looked like this: |
86 |
|
87 |
config_eth0="172.16.1.1/24" |
88 |
mac_eth0="00:18:f3:97:17:72" |
89 |
rc_net_eth0_provide="!net" |
90 |
rc_net_eth0_need="local" |
91 |
|
92 |
And the local.d script executed |
93 |
|
94 |
ip link set dev dummy0 name eth0 |
95 |
|
96 |
In comparison, the netctl configuration has everything in one place: |
97 |
|
98 |
# cat /etc/netctl/dummy |
99 |
Description='A dummy interface (for MATLAB)' |
100 |
Interface=eth0 |
101 |
Connection=dummy |
102 |
IP=static |
103 |
Address=172.16.1.1 |
104 |
IPCustom=( 'link set dev eth0 address 00:18:f3:97:17:72' ) |
105 |
|
106 |
It also takes care of loading the dummy kernel module, so I don't don't need an |
107 |
/etc/modules-load.d/ entry, whereas with netifrc/OpenRC I needed to load it |
108 |
manually via /etc/conf./modules (though maybe that has changed?). |
109 |
|
110 |
== Stuff I liked == |
111 |
|
112 |
If you want to skip this, the questions are in the next section. |
113 |
|
114 |
=== Pleasant surprises === |
115 |
|
116 |
Some surprising things worked out of the box, for example all /etc/local.d/ |
117 |
files are dynamically converted to units at run-time and executed. I hardly |
118 |
had to migrate anything. The one exception was chrony, where I had to override |
119 |
the service file to add extra command line flags that don't have corresponding |
120 |
configuration file entries. |
121 |
|
122 |
On my desktop I had to add network dependencies to some socket units so that |
123 |
they wouldn't start before the network they're supposed to listen on is fully |
124 |
configured (see the question below). Otherwise, it just had a few more things |
125 |
that needed doing, but that is the nature of running services on it (dovecot, |
126 |
postfix, and samba). |
127 |
|
128 |
=== The Journal === |
129 |
|
130 |
I like the journal. No, sorry, I *really* *really* like the journal. I like |
131 |
the filters you can apply (e.g., limiting the output by unit via the -u flag), |
132 |
the priority system, the automatic use of ACLs so that you can see your own |
133 |
user's logs. I also think that it's a nice detail that "systemctl status -u" |
134 |
will show the last lines of log output. This actually helped me at work :-) . |
135 |
|
136 |
=== Socket activation === |
137 |
|
138 |
I especially learned to like it after reading the early "systemd for admins" |
139 |
articles, which made the implications of the design more clear. I definitely |
140 |
like the ability to have a service start on-demand instead of spending 99.99% |
141 |
of its time idle. Finally, I also like the simplicity of the C API from |
142 |
systemd/sd-daemon.h. |
143 |
|
144 |
=== Miscellanea === |
145 |
|
146 |
Some things work better, e.g., closing the laptop's lid suspends the laptop |
147 |
automatically without me having to configure anything. My desktop is *almost* |
148 |
there, see the questions below. |
149 |
|
150 |
Systemd can restart itself, e.g., for upgrades. Nice! |
151 |
|
152 |
Systemd-analyze is really nice. |
153 |
|
154 |
Systemd exposes various system features that require extra work to set up |
155 |
otherwise. The example that made me think of this is "systemctl kexec", but |
156 |
from reading Leannart Poettering's blog series, this is one of the goals of |
157 |
systemd. I can definitely sympathise with that. |
158 |
|
159 |
== Questions === |
160 |
|
161 |
=== ACPID: needed or not? === |
162 |
|
163 |
Does acpid provide anything that systemd does not, and if so, what kind of |
164 |
"conflicts" might I see? The Gentoo Wiki page says that acpid is likely not |
165 |
needed. |
166 |
|
167 |
FWIW, I already unmerged it and have not noticed any missing functionality, |
168 |
even after over a week of regular usage. So I'm tending towards "no, not |
169 |
needed". |
170 |
|
171 |
=== Timers === |
172 |
|
173 |
Can a systemd timer depend on a mount point such that it waits until the mount |
174 |
point exists before running? Or will it fail after a timeout? I want to |
175 |
research this myself, but haven't gotten around to it yet. |
176 |
|
177 |
The problem I have is that my external HDD does not come up properly on cold |
178 |
boot, so that I have to unplug it and plug it back in in order for the kernel |
179 |
to fully initialise it and for it to mount, which is problematic for my backup |
180 |
fcron jobs, since they have &bootrun set. This means that the backup script |
181 |
will fail, unless I'm a) fast enough at re-plugging the HDD, and b) fast enough |
182 |
at logging in (so that my automounter mounts the HDD. I will then have to |
183 |
manually re-run it (i.e., fcrondyn -x "run <ID>") or wait for the next time |
184 |
it's supposed to run. |
185 |
|
186 |
Naturally, I would like a more robust system than that, and hope that systemd |
187 |
timers can make my life easier here. |
188 |
|
189 |
=== User units === |
190 |
|
191 |
I would like to convert some programs I start in .xprofile to units that are |
192 |
started by my users's systemd instance. I started off with mpd, but it doesn't |
193 |
start automatically ("systemctl --user start mpd" works fine, though), even |
194 |
though it's enabled: |
195 |
|
196 |
% systemctl --user status mpd |
197 |
● mpd.service - Music Player Daemon |
198 |
Loaded: loaded (/usr/lib64/systemd/system/mpd.service; enabled) |
199 |
Active: active (running) since Di 2015-02-24 19:39:46 CET; 1h 6min ago |
200 |
Main PID: 1091 (mpd) |
201 |
CGroup: /user.slice/user-1000.slice/user@××××.service/mpd.service |
202 |
└─1091 /usr/bin/mpd --no-daemon |
203 |
|
204 |
Feb 24 19:39:46 marcec systemd[384]: Started Music Player Daemon. |
205 |
[...] |
206 |
|
207 |
Also: |
208 |
|
209 |
% tree .config/systemd/ |
210 |
.config/systemd/ |
211 |
└── user |
212 |
├── mpd.service -> /usr/lib64/systemd/system/mpd.service |
213 |
└── multi-user.target.wants |
214 |
└── mpd.service -> /home/marcec/.config/systemd/user/mpd.service |
215 |
|
216 |
Is the symlink the problem? Do I have to create an actual file? Is the |
217 |
target.wants wrong? |
218 |
|
219 |
=== Suspend on the desktop === |
220 |
|
221 |
Like I mentioned above, my Desktop can *almost* suspend reliably, after trying |
222 |
it out once every year or two (it's over 8 years old). Mostly it would just |
223 |
not wake back up. The latest status (before systemd) was that the kernel |
224 |
crashed after waking up (but I think that was a known bug that was fixed in the |
225 |
meantime). |
226 |
|
227 |
Now with systemd, it wakes back up properly, but one of the soundcard drivers |
228 |
(ice1724) is apparently unreliable, so that sound stops working after wakeup. |
229 |
Plus, access to the soundcard was blocked by rtkit. I believe what one would |
230 |
normally do is unload the module before suspending, but the only way I could |
231 |
find to tell systemd to do that requires creating a file in /usr (as done here, |
232 |
for example: http://forums.fedoraforum.org/showthread.php?t=294065). Is there |
233 |
a better way? |
234 |
|
235 |
=== Dovecot and socket activation === |
236 |
|
237 |
Dovecot gave me problems with socket activation, I kept getting errors like the |
238 |
following: |
239 |
|
240 |
Feb 20 22:58:19 marcec dovecot[6500]: master: Panic: io_add(0x1) called |
241 |
twice fd=4, callback=0x40a970 -> 0x40a970 Feb 20 22:58:19 marcec |
242 |
dovecot[6500]: master: Error: Raw |
243 |
backtrace: /usr/lib64/dovecot/libdovecot.so.0(+0x6accf) [0x7f42b9300ccf] |
244 |
-> /usr/lib64/dovecot/libdovecot.so.0(i_syslog_fatal_handler |
245 |
|
246 |
I don't know who's at fault here, systemd or dovecot, but I had to simplify the |
247 |
configuration a bit: |
248 |
|
249 |
diff --git a/dovecot/conf.d/10-master.conf b/dovecot/conf.d/10-master.conf |
250 |
index ddbde28..c0ca867 100644 |
251 |
--- a/dovecot/conf.d/10-master.conf |
252 |
+++ b/dovecot/conf.d/10-master.conf |
253 |
@@ -16,11 +16,11 @@ |
254 |
|
255 |
service imap-login { |
256 |
inet_listener imap { |
257 |
- address = ::1, 127.0.0.1, 172.16.0.1 |
258 |
+ address = ::1, 172.16.0.1 |
259 |
port = 10087 |
260 |
} |
261 |
inet_listener imaps { |
262 |
- address = ::1, 127.0.0.1, 172.16.0.1 |
263 |
+ address = ::1, 172.16.0.1 |
264 |
port = 10887 |
265 |
#ssl = yes |
266 |
} |
267 |
diff --git a/systemd/system/dovecot.socket.d/sockets.conf |
268 |
b/systemd/system/dovecot.socket.d/sockets.conf index bcc29c6..368d461 100644 |
269 |
--- a/systemd/system/dovecot.socket.d/sockets.conf |
270 |
+++ b/systemd/system/dovecot.socket.d/sockets.conf |
271 |
@@ -1,8 +1,6 @@ |
272 |
[Socket] |
273 |
ListenStream= |
274 |
-ListenStream=127.0.0.1:10087 |
275 |
ListenStream=172.16.0.1:10087 |
276 |
ListenStream=[::1]:10087 |
277 |
-ListenStream=127.0.0.1:10887 |
278 |
ListenStream=172.16.0.1:10887 |
279 |
ListenStream=[::1]:10887 |
280 |
|
281 |
Note that it also worked if I removed 127.0.0.1 from imap, and 172.16.0.1 from |
282 |
imaps (or, IIRC, vice versa). I'm fine with the configuration being like this, |
283 |
but I'm nonetheless baffled by the necessity. I couldn't even find a bug |
284 |
report or ML post. |
285 |
|
286 |
=== Depending on a specific network interface === |
287 |
|
288 |
Some socket units failed to start at first, due to "resource" errors. So I |
289 |
made them depend on netctl@bridge via *.d/requires.conf files like so: |
290 |
|
291 |
[Unit] |
292 |
Requires=netctl@××××××.service |
293 |
After=netctl@××××××.service |
294 |
|
295 |
That fixed the errors, but is it the correct way to depend on that interface |
296 |
(ignoring the fact that I could have put symlinks at the right place instead)? |
297 |
|
298 |
=== dmesg and syslog === |
299 |
|
300 |
On the laptop I didn't immediately stop running syslog-ng. Following a thread |
301 |
on gentoo-user about the journal complaining about messages not being forwarded |
302 |
to syslog-ng, I got curious and checked the laptop today. |
303 |
|
304 |
What I did was run |
305 |
|
306 |
diff -U8 <(zcat /var/log/messages-*) <(journalctl) |
307 |
|
308 |
and look for differences in the time frame where both were running (note |
309 |
that /var/log/messages is empty, so I only checked the rotated logs). |
310 |
|
311 |
First of all, while I clearly remember seeing similar messages about "missing |
312 |
messages", I couldn't find any in either the journal or syslogs output. Maybe |
313 |
I mixed them up with "Forward time jump detected" messages from chrony? But |
314 |
those are too rare, unless I noticed one right after resuming from suspend and |
315 |
got mixed up then? I think that I would like confirmation that those messages |
316 |
are actually logged properly, and where. |
317 |
|
318 |
However, I did find something unexpected. I haven't looked deeply yet, but I |
319 |
noticed some dmesg entries not ending up in the journal (i.e., a bunch of "-" |
320 |
lines in-between the "+" lines in the diff output). Did I do something wrong, or |
321 |
is this known behaviour when running the journal and syslog-ng simultaneously? |
322 |
I'll look more closely tomorrow, but wondered if anybody here noticed anything |
323 |
similar. |
324 |
|
325 |
== The End == |
326 |
|
327 |
*phew* |
328 |
|
329 |
Of course, some of the complications will go away once I've gotten around to |
330 |
turning my desktop back into a pure desktop and not the desktop/server/router |
331 |
hybrid it is now, but that will have to wait. |
332 |
|
333 |
Greetings |
334 |
-- |
335 |
Marc Joliet |
336 |
-- |
337 |
"People who think they know everything really annoy those of us who know we |
338 |
don't" - Bjarne Stroustrup |