1 |
Am Tue, 24 Feb 2015 16:44:59 -0500 |
2 |
schrieb Rich Freeman <rich0@g.o>: |
3 |
|
4 |
> Lots of stuff here. I'm only replying where I think I can add value. |
5 |
> |
6 |
> On Tue, Feb 24, 2015 at 3:15 PM, Marc Joliet <marcec@×××.de> wrote: |
7 |
> > |
8 |
> > == Things I have *not* gotten rid of (yet) == |
9 |
> > |
10 |
> > Fcron is still around, mainly because packages might rely on it being there |
11 |
> > (e.g., man-db and mlocate install files there), but also because I haven't |
12 |
> > researched systemd timers yet. |
13 |
> |
14 |
> My fault. :) I have sys-process/systemd-cron in my rich0 overlay but |
15 |
> I've been too lazy to get it into the main tree (I need to check to |
16 |
> see what units if any I had to tweak from what gets installed and |
17 |
> merge those back into the package). This is a set of timer/service |
18 |
> units that will run all the /etc/cron.*/ jobs. They'll run in series |
19 |
> and not in parallel as they would if you turned them into individual |
20 |
> timer scripts, but it is a great way to just integrate the scripts |
21 |
> packages already are providing. It also has a crontab generator, but |
22 |
> I don't think it works with fcrontab so I have not tested this. |
23 |
> Generators are just one of those little things I love about systemd. |
24 |
|
25 |
That sounds great! I'll be looking forward to this :) . |
26 |
|
27 |
(Although, sadly, it does appear as if ebuilds getting stuck in overlays happens |
28 |
much too often these days.) |
29 |
|
30 |
> > |
31 |
> > I plan on uninstalling syslog-ng, but haven't done so yet. I simply feel |
32 |
> > better waiting a bit, even though I don't run it anymore. Man, I feel silly |
33 |
> > after typing that... |
34 |
> |
35 |
> Yeah, took me a while to uninstall it, but I don't find much value in |
36 |
> running both. |
37 |
|
38 |
Precisely. It's more a "but what if...!" kind of worry. |
39 |
|
40 |
> > |
41 |
> > == Network migration on my desktop == |
42 |
> > |
43 |
> > My desktop has a somewhat more complicated network setup than the laptop (which |
44 |
> > uses NetworkManager). The wan0 network device is no problem, but I also have a |
45 |
> > bridge with one physical device connected to it, and one dummy device. ... |
46 |
> > I originally ignored systemd-networkd because I keep |
47 |
> > hearing that it's only for simple networks, but after looking at the man page |
48 |
> > it appears that it can do (almost) everything that I needed it to, although I'm |
49 |
> > not sure about dummy device support. |
50 |
> |
51 |
> Here is what I'm doing for a bridge - I can't vouch for dummy devices |
52 |
> but I wouldn't be surprised if it works (remember, these are the guys |
53 |
> doing udev too): |
54 |
> cd /etc/systemd/network/ |
55 |
> |
56 |
> cat brkvm.netdev |
57 |
> [NetDev] |
58 |
> Name=brkvm |
59 |
> Kind=bridge |
60 |
> |
61 |
> |
62 |
> cat brkvm.network |
63 |
> [Match] |
64 |
> Name=brkvm |
65 |
> |
66 |
> [Network] |
67 |
> DNS=192.168.0.5 |
68 |
> Address=192.168.0.5/24 |
69 |
> Gateway=192.168.0.21 |
70 |
> |
71 |
> |
72 |
> cat eth-bridge.network |
73 |
> [Match] |
74 |
> Name=e* |
75 |
> |
76 |
> [Network] |
77 |
> Bridge=brkvm |
78 |
> |
79 |
> |
80 |
> If you're using persistent names you might need to tweak the Name in |
81 |
> the last one slightly so that it matches whatever you're using. |
82 |
|
83 |
That looks nice, I like that the bridge device is distinct from the bridge |
84 |
network, is distinct from other devices attached to it. This might help in |
85 |
getting unit dependencies right. I'll try it out this weekend. |
86 |
|
87 |
My primary concern with networkd would be that it is very new, and thus not as |
88 |
well tested as other solutions. While netctl is also fairly new, and |
89 |
I'm using that with no problems, it uses well-known DHCP clients, while it |
90 |
appears that networkd implements its own. |
91 |
|
92 |
But I'll give it a whirl anyway ;) . |
93 |
|
94 |
> > === Timers === |
95 |
> > |
96 |
> > Can a systemd timer depend on a mount point such that it waits until the mount |
97 |
> > point exists before running? Or will it fail after a timeout? I want to |
98 |
> > research this myself, but haven't gotten around to it yet. |
99 |
> |
100 |
> So, timer units are units, and units can have dependencies, and mounts |
101 |
> can be dependencies since mounts are units. However, if you set the |
102 |
> dependency on the timer itself, then the timer won't start running |
103 |
> until the mount exists. You probably want the depencency to be on the |
104 |
> service started by the timer (so the timer is watching the clock, but |
105 |
> the service won't start without the mount). |
106 |
|
107 |
Wait, so the timer won't start watching the clock until its dependencies are |
108 |
met (i.e, the mount point appears)? Is that what you mean? Because that might |
109 |
be more in line with what I want (though I'm not sure yet). |
110 |
|
111 |
> If you set a |
112 |
> Requires=foo.mount and After=foo.mount, then the service shouldn't run |
113 |
> unless foo.mount is available. I suspect systemd will attempt to |
114 |
> mount the filesystem when it runs the service, and you'll get units in |
115 |
> the failed state if that doesn't work. |
116 |
> |
117 |
> However, I haven't tested any of this. I suspect it wouldn't take |
118 |
> much to work this out. I have a mount dependency in one of my |
119 |
> services. Just look at the mount units in /run/systemd/generator for |
120 |
> the name of the mount unit systemd is creating from fstab. |
121 |
|
122 |
Right, so IIUC, I would have a oneshot service that does the backup, and the timer |
123 |
runs that, and of course the timer can depend on the mount point. And if the |
124 |
mount point doesn't exist, then the service started by the timer will fail. |
125 |
|
126 |
What I would prefer to have is a timer that only runs if *both* the time *and* |
127 |
mount conditions are met. Skimming the man page, this does not seem possible. |
128 |
I suppose it would be nice if timers learned "conditions" on which they should |
129 |
wait in addition to the time condition, but maybe that's outside the scope of |
130 |
systemd? |
131 |
|
132 |
But my confidence that at the very least something better than what I have now |
133 |
will be possible, I'll just have to take the time and read the man pages |
134 |
properly. |
135 |
|
136 |
> > === Depending on a specific network interface === |
137 |
> > |
138 |
> > Some socket units failed to start at first, due to "resource" errors. So I |
139 |
> > made them depend on netctl@bridge via *.d/requires.conf files like so: |
140 |
> > |
141 |
> > [Unit] |
142 |
> > Requires=netctl@××××××.service |
143 |
> > After=netctl@××××××.service |
144 |
> > |
145 |
> > That fixed the errors, but is it the correct way to depend on that interface |
146 |
> > (ignoring the fact that I could have put symlinks at the right place instead)? |
147 |
> |
148 |
> Following my networkd scripts above, I suspect that something like |
149 |
> this /might/ work but I haven't tested it: |
150 |
> Requires=sys-subsystem-net-devices-brkvm.device |
151 |
> After=sys-subsystem-net-devices-brkvm.device |
152 |
> |
153 |
> Again, another example of the udev integration - you get device units |
154 |
> for devices. That also lets you do things like start a service when a |
155 |
> device is activated, have dependencies, etc. You should look at the |
156 |
> list of units sometime - you can also do things like run a service |
157 |
> when a file is modified (no need to have a helper program watching it |
158 |
> with fnotify, etc). |
159 |
|
160 |
Right, I really do like that about systemd, too. It's much more thorough than |
161 |
other systems (in several ways). The mount point units generated from fstab |
162 |
are one example, but I also noticed that each script in /etc/local.d/ gets the |
163 |
same treatment and is exposed as its own unit. |
164 |
|
165 |
The more I use systemd, the more I realise why it made sense to merge the udev |
166 |
project into systemd: they both play off each others capabilities quite |
167 |
nicely (udev giving systemd extra information and events to act upon, and |
168 |
systemd reacting to udev's events and doing the appropriate thing). |
169 |
|
170 |
Diving into systemd on a whim really was the best way to see what all the fuss |
171 |
was about, and so far it was worth it. |
172 |
|
173 |
> Also, I think Requires basically implies Wants as well, so if that |
174 |
> network device doesn't exist and the service tries to start, systemd |
175 |
> might try to create that device, if possible. |
176 |
> |
177 |
> Now, the device existing does not necessarily mean that it has an IP, |
178 |
> working DNS, etc. I don't know if there is any way to have a |
179 |
> dependency on a specific configured network. That might be a great |
180 |
> question to ask the systemd devs. |
181 |
|
182 |
Sure, if nobody here gives an authoritative answer, I'll ask there. People: |
183 |
you have until the weekend ;) . |
184 |
|
185 |
Thanks to everyone for the responses so far! |
186 |
-- |
187 |
Marc Joliet |
188 |
-- |
189 |
"People who think they know everything really annoy those of us who know we |
190 |
don't" - Bjarne Stroustrup |