1 |
Am Sun, 1 Mar 2015 08:34:19 -0500 |
2 |
schrieb Rich Freeman <rich0@g.o>: |
3 |
|
4 |
> On Sun, Mar 1, 2015 at 7:48 AM, Marc Joliet <marcec@×××.de> wrote: |
5 |
> > |
6 |
> > The problem with conditions (as they exist in systemd currently) is the same as |
7 |
> > with dependencies: the unit does not wait until the condition is met, but |
8 |
> > immediately stops (only that it doesn't enter a failed state). I mean, this is |
9 |
> > what conditions in systemd are *supposed* to do, and they do they're |
10 |
> > designated job, but I would like the timer to wait until the condition is met |
11 |
> > and *then* run the job. I.e., I want a *delay*. |
12 |
> |
13 |
> The timer keeps running if you set the dependency on the service. So, |
14 |
> next time the timer runs, it will try again. You might want to just |
15 |
> set an hourly job and have it check for a successful run in the last |
16 |
> day or whatever. |
17 |
> |
18 |
> I don't know if restart=on-failure or on-abnormal applies if the |
19 |
> service fails to run in the first place. You might try setting that |
20 |
> with a suitable restartsec=### setting. That might be a better way to |
21 |
> get the behavior you want if it works. |
22 |
|
23 |
I think I tried that (with a Requisite dependency, because I didn't want the |
24 |
drive to be mounted automatically by the service). I'm certain that it did not |
25 |
work, and that it could not. Specifically, what I remember seeing is the unit |
26 |
trying to start and immediately failing due to the missing dependency. |
27 |
|
28 |
Which makes sense, because Restart= applies to the program being executed |
29 |
(i.e., processes started by Exec*), not the service unit itself. If the failure |
30 |
happens before that (e.g., a required dependency is not met) then it doesn't |
31 |
even get to the point where it can check a return code, so it *cannot* apply. |
32 |
|
33 |
So the way I'm using Restart= is about as good as it gets. |
34 |
|
35 |
But actually, while putting off finishing this email, I came to the realisation |
36 |
that I could of course use WantedBy= in [Install], and following that idea I |
37 |
ended up with the following [Unit] and [Install] sections: |
38 |
|
39 |
[Unit] |
40 |
Description=Run hourly backups (timer) |
41 |
Requisite=media-MARCEC_BACKUP.mount |
42 |
BindsTo=media-MARCEC_BACKUP.mount |
43 |
After=media-MARCEC_BACKUP.mount |
44 |
|
45 |
[Install] |
46 |
WantedBy=timers.target |
47 |
WantedBy=media-MARCEC_BACKUP.mount |
48 |
|
49 |
So the mount point and the timer both depend on each other (with the mount unit |
50 |
starting first), so the mount tries to start the timer and vice versa, but only |
51 |
the timer fails if the mount point doesn't exist. And the BindsTo sees to it |
52 |
that the timer disappears if the mount does. Preliminary tests show that it |
53 |
works: unmounting with udiskie shows that the backup timer disappears, and it |
54 |
re-appears after mounting the file system again. |
55 |
|
56 |
I'll have to see what the behaviour is during a cold boot. The Requisite |
57 |
dependency on the mount point *should* make the Restart line in the |
58 |
corresponding service obsolete, since the WantedBy should make the timer start |
59 |
once the mount point shows up. I could probably alternatively use |
60 |
ConditionPathIsMountPoint instead, but I think I prefer the timer failing. |
61 |
|
62 |
I also have to admit here that I am still not sure *what* I want (sorry), so I |
63 |
think I'll just have stop fiddling with this for now and see how this works out |
64 |
in practice. |
65 |
|
66 |
Regardless: thoughts? |
67 |
|
68 |
Greetings |
69 |
-- |
70 |
Marc Joliet |
71 |
-- |
72 |
"People who think they know everything really annoy those of us who know we |
73 |
don't" - Bjarne Stroustrup |