1 |
Am Wed, 25 Feb 2015 19:25:08 +0100 |
2 |
schrieb Marc Joliet <marcec@×××.de>: |
3 |
|
4 |
> Am Wed, 25 Feb 2015 07:01:59 -0500 |
5 |
> schrieb Rich Freeman <rich0@g.o>: |
6 |
> |
7 |
> > On Wed, Feb 25, 2015 at 2:50 AM, Marc Joliet <marcec@×××.de> wrote: |
8 |
> > > Am Tue, 24 Feb 2015 16:44:59 -0500 |
9 |
> > > schrieb Rich Freeman <rich0@g.o>: |
10 |
> > > |
11 |
> > >> > === Timers === |
12 |
> > >> > |
13 |
> > >> > Can a systemd timer depend on a mount point such that it waits until the mount |
14 |
> > >> > point exists before running? Or will it fail after a timeout? I want to |
15 |
> > >> > research this myself, but haven't gotten around to it yet. |
16 |
> > >> |
17 |
> > >> So, timer units are units, and units can have dependencies, and mounts |
18 |
> > >> can be dependencies since mounts are units. However, if you set the |
19 |
> > >> dependency on the timer itself, then the timer won't start running |
20 |
> > >> until the mount exists. You probably want the depencency to be on the |
21 |
> > >> service started by the timer (so the timer is watching the clock, but |
22 |
> > >> the service won't start without the mount). |
23 |
> > > |
24 |
> > > Wait, so the timer won't start watching the clock until its dependencies are |
25 |
> > > met (i.e, the mount point appears)? Is that what you mean? Because that might |
26 |
> > > be more in line with what I want (though I'm not sure yet). |
27 |
> > |
28 |
> > If you set the dependency on the timer, then the timer doesn't start |
29 |
> > watching the clock until they're met. If you set the dependency on |
30 |
> > the service started by the timer then it will watch the clock but not |
31 |
> > launch the service if the dependency isn't met. You can set the |
32 |
> > dependency in either or both places. The timer and the service are |
33 |
> > both units. |
34 |
> |
35 |
> OK, I think I got it. |
36 |
|
37 |
I finally looked at this more closely yesterday. No, dependencies don't do |
38 |
what I want. If a dependency is not met, a unit goes into a failed state. |
39 |
Since the problem is that my external drive doesn't show up properly until I |
40 |
unplug it and plug it back in (well, strictly speaking, its device name shows |
41 |
up, but not its partitions), that won't work because that would require manual |
42 |
intervention, which I would very much like to avoid. |
43 |
|
44 |
> > >> If you set a |
45 |
> > >> Requires=foo.mount and After=foo.mount, then the service shouldn't run |
46 |
> > >> unless foo.mount is available. I suspect systemd will attempt to |
47 |
> > >> mount the filesystem when it runs the service, and you'll get units in |
48 |
> > >> the failed state if that doesn't work. |
49 |
|
50 |
Exactly, setting a dependency on a mount point will make systemd attempt to |
51 |
mount the file system before starting the unit. Its the fact that it goes into |
52 |
a failed state if that attempt fails that's the problem. Again: manual |
53 |
intervention. |
54 |
|
55 |
> > >> However, I haven't tested any of this. I suspect it wouldn't take |
56 |
> > >> much to work this out. I have a mount dependency in one of my |
57 |
> > >> services. Just look at the mount units in /run/systemd/generator for |
58 |
> > >> the name of the mount unit systemd is creating from fstab. |
59 |
> > > |
60 |
> > > Right, so IIUC, I would have a oneshot service that does the backup, and the timer |
61 |
> > > runs that, and of course the timer can depend on the mount point. And if the |
62 |
> > > mount point doesn't exist, then the service started by the timer will fail. |
63 |
> > > |
64 |
> > > What I would prefer to have is a timer that only runs if *both* the time *and* |
65 |
> > > mount conditions are met. Skimming the man page, this does not seem possible. |
66 |
> > > I suppose it would be nice if timers learned "conditions" on which they should |
67 |
> > > wait in addition to the time condition, but maybe that's outside the scope of |
68 |
> > > systemd? |
69 |
> > |
70 |
> > I think if you just set the dependency on the service you'll get the |
71 |
> > behavior you desire. Systemd will try to mount the backup filesystem, |
72 |
> > and if that fails it won't run the backup. |
73 |
> > |
74 |
> > You can set conditions on units as well, like only running if they're |
75 |
> > on AC power or on amd64 or to run one unit the first time you start a |
76 |
> > service and a different unit every other time. Some of that was |
77 |
> > designed to implement some of the stateless system features they're |
78 |
> > adding to systemd. |
79 |
> |
80 |
> Right, I'll have a look at them. |
81 |
|
82 |
The problem with conditions (as they exist in systemd currently) is the same as |
83 |
with dependencies: the unit does not wait until the condition is met, but |
84 |
immediately stops (only that it doesn't enter a failed state). I mean, this is |
85 |
what conditions in systemd are *supposed* to do, and they do they're |
86 |
designated job, but I would like the timer to wait until the condition is met |
87 |
and *then* run the job. I.e., I want a *delay*. |
88 |
|
89 |
An example of where something like this exists is fcron's lavg* options, where |
90 |
the jobs is delayed until the specified load average is reached. I want this, |
91 |
only for mount points. |
92 |
|
93 |
Another possibility would be something akin to PartOf that would additionally |
94 |
link two units at *startup*, i.e., the depending unit starts when its |
95 |
dependency appears. Then the timers would come and go along with the mount |
96 |
point, and at bootup, when the drive doesn't show up properly, once I get it |
97 |
going the timers show up and elapse appropriately. However, I'm not sure |
98 |
whether that would be a good/robust system design (e.g., would that mask error |
99 |
modes I care about?). |
100 |
|
101 |
*sigh* |
102 |
|
103 |
Maybe I'm over-thinking this. |
104 |
|
105 |
Anyway, what I ended up doing is setting Restart=on-failure with appropriate |
106 |
intervals so that I get a five minute window to unplug the drive and plug it |
107 |
back in. My backup script already returns appropriate error codes, so this |
108 |
just worked. |
109 |
|
110 |
I'm not entirely happy, but it's still better (in various ways) than what I had |
111 |
with fcron, despite the greater verbosity of systemd timers compared to crontab |
112 |
entries. |
113 |
|
114 |
Greetings |
115 |
-- |
116 |
Marc Joliet |
117 |
-- |
118 |
"People who think they know everything really annoy those of us who know we |
119 |
don't" - Bjarne Stroustrup |