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 |