Gentoo Archives: gentoo-amd64

From: Rich Freeman <rich0@g.o>
To: gentoo-amd64@l.g.o
Subject: Re: [gentoo-amd64] Systemd migration: opinion and questions
Date: Tue, 24 Feb 2015 21:45:04
Message-Id: CAGfcS_k_Lua_eW+x2yWmh5+6A2JXQC-xwCqv0_5DU8cJrzj9Xw@mail.gmail.com
In Reply to: [gentoo-amd64] Systemd migration: opinion and questions by Marc Joliet
1 Lots of stuff here. I'm only replying where I think I can add value.
2
3 On Tue, Feb 24, 2015 at 3:15 PM, Marc Joliet <marcec@×××.de> wrote:
4 >
5 > == Things I have *not* gotten rid of (yet) ==
6 >
7 > Fcron is still around, mainly because packages might rely on it being there
8 > (e.g., man-db and mlocate install files there), but also because I haven't
9 > researched systemd timers yet.
10
11 My fault. :) I have sys-process/systemd-cron in my rich0 overlay but
12 I've been too lazy to get it into the main tree (I need to check to
13 see what units if any I had to tweak from what gets installed and
14 merge those back into the package). This is a set of timer/service
15 units that will run all the /etc/cron.*/ jobs. They'll run in series
16 and not in parallel as they would if you turned them into individual
17 timer scripts, but it is a great way to just integrate the scripts
18 packages already are providing. It also has a crontab generator, but
19 I don't think it works with fcrontab so I have not tested this.
20 Generators are just one of those little things I love about systemd.
21
22 >
23 > I plan on uninstalling syslog-ng, but haven't done so yet. I simply feel
24 > better waiting a bit, even though I don't run it anymore. Man, I feel silly
25 > after typing that...
26
27 Yeah, took me a while to uninstall it, but I don't find much value in
28 running both.
29
30 >
31 > == Network migration on my desktop ==
32 >
33 > My desktop has a somewhat more complicated network setup than the laptop (which
34 > uses NetworkManager). The wan0 network device is no problem, but I also have a
35 > bridge with one physical device connected to it, and one dummy device. ...
36 > I originally ignored systemd-networkd because I keep
37 > hearing that it's only for simple networks, but after looking at the man page
38 > it appears that it can do (almost) everything that I needed it to, although I'm
39 > not sure about dummy device support.
40
41 Here is what I'm doing for a bridge - I can't vouch for dummy devices
42 but I wouldn't be surprised if it works (remember, these are the guys
43 doing udev too):
44 cd /etc/systemd/network/
45
46 cat brkvm.netdev
47 [NetDev]
48 Name=brkvm
49 Kind=bridge
50
51
52 cat brkvm.network
53 [Match]
54 Name=brkvm
55
56 [Network]
57 DNS=192.168.0.5
58 Address=192.168.0.5/24
59 Gateway=192.168.0.21
60
61
62 cat eth-bridge.network
63 [Match]
64 Name=e*
65
66 [Network]
67 Bridge=brkvm
68
69
70 If you're using persistent names you might need to tweak the Name in
71 the last one slightly so that it matches whatever you're using.
72
73 >
74 > === Timers ===
75 >
76 > Can a systemd timer depend on a mount point such that it waits until the mount
77 > point exists before running? Or will it fail after a timeout? I want to
78 > research this myself, but haven't gotten around to it yet.
79
80 So, timer units are units, and units can have dependencies, and mounts
81 can be dependencies since mounts are units. However, if you set the
82 dependency on the timer itself, then the timer won't start running
83 until the mount exists. You probably want the depencency to be on the
84 service started by the timer (so the timer is watching the clock, but
85 the service won't start without the mount). If you set a
86 Requires=foo.mount and After=foo.mount, then the service shouldn't run
87 unless foo.mount is available. I suspect systemd will attempt to
88 mount the filesystem when it runs the service, and you'll get units in
89 the failed state if that doesn't work.
90
91 However, I haven't tested any of this. I suspect it wouldn't take
92 much to work this out. I have a mount dependency in one of my
93 services. Just look at the mount units in /run/systemd/generator for
94 the name of the mount unit systemd is creating from fstab.
95
96 > === Depending on a specific network interface ===
97 >
98 > Some socket units failed to start at first, due to "resource" errors. So I
99 > made them depend on netctl@bridge via *.d/requires.conf files like so:
100 >
101 > [Unit]
102 > Requires=netctl@××××××.service
103 > After=netctl@××××××.service
104 >
105 > That fixed the errors, but is it the correct way to depend on that interface
106 > (ignoring the fact that I could have put symlinks at the right place instead)?
107
108 Following my networkd scripts above, I suspect that something like
109 this /might/ work but I haven't tested it:
110 Requires=sys-subsystem-net-devices-brkvm.device
111 After=sys-subsystem-net-devices-brkvm.device
112
113 Again, another example of the udev integration - you get device units
114 for devices. That also lets you do things like start a service when a
115 device is activated, have dependencies, etc. You should look at the
116 list of units sometime - you can also do things like run a service
117 when a file is modified (no need to have a helper program watching it
118 with fnotify, etc).
119
120 Also, I think Requires basically implies Wants as well, so if that
121 network device doesn't exist and the service tries to start, systemd
122 might try to create that device, if possible.
123
124 Now, the device existing does not necessarily mean that it has an IP,
125 working DNS, etc. I don't know if there is any way to have a
126 dependency on a specific configured network. That might be a great
127 question to ask the systemd devs.
128
129 --
130 Rich

Replies

Subject Author
Re: [gentoo-amd64] Systemd migration: opinion and questions Marc Joliet <marcec@×××.de>
[gentoo-amd64] Re: Systemd migration: opinion and questions Duncan <1i5t5.duncan@×××.net>