Re: Systemd migration: opinion and questions

Am Sun, 1 Mar 2015 08:34:19 -0500
schrieb Rich Freeman <[email protected]>:

> On Sun, Mar 1, 2015 at 7:48 AM, Marc Joliet <[email protected]> wrote:
> >
> > The problem with conditions (as they exist in systemd currently) is the same as
> > with dependencies: the unit does not wait until the condition is met, but
> > immediately stops (only that it doesn't enter a failed state).  I mean, this is
> > what conditions in systemd are *supposed* to do, and they do they're
> > designated job, but I would like the timer to wait until the condition is met
> > and *then* run the job. I.e., I want a *delay*.
> 
> The timer keeps running if you set the dependency on the service.  So,
> next time the timer runs, it will try again.  You might want to just
> set an hourly job and have it check for a successful run in the last
> day or whatever.
> 
> I don't know if restart=on-failure or on-abnormal applies if the
> service fails to run in the first place.  You might try setting that
> with a suitable restartsec=### setting.  That might be a better way to
> get the behavior you want if it works.

I think I tried that (with a Requisite dependency, because I didn't want the
drive to be mounted automatically by the service).  I'm certain that it did not
work, and that it could not.  Specifically, what I remember seeing is the unit
trying to start and immediately failing due to the missing dependency.

Which makes sense, because Restart= applies to the program being executed
(i.e., processes started by Exec*), not the service unit itself. If the failure
happens before that (e.g., a required dependency is not met) then it doesn't
even get to the point where it can check a return code, so it *cannot* apply.

So the way I'm using Restart= is about as good as it gets.

But actually, while putting off finishing this email, I came to the realisation
that I could of course use WantedBy= in [Install], and following that idea I
ended up with the following [Unit] and [Install] sections:

    [Unit]
    Description=Run hourly backups (timer)
    Requisite=media-MARCEC_BACKUP.mount
    BindsTo=media-MARCEC_BACKUP.mount
    After=media-MARCEC_BACKUP.mount

    [Install]
    WantedBy=timers.target
    WantedBy=media-MARCEC_BACKUP.mount

So the mount point and the timer both depend on each other (with the mount unit
starting first), so the mount tries to start the timer and vice versa, but only
the timer fails if the mount point doesn't exist.  And the BindsTo sees to it
that the timer disappears if the mount does.  Preliminary tests show that it
works: unmounting with udiskie shows that the backup timer disappears, and it
re-appears after mounting the file system again.

I'll have to see what the behaviour is during a cold boot.  The Requisite
dependency on the mount point *should* make the Restart line in the
corresponding service obsolete, since the WantedBy should make the timer start
once the mount point shows up.  I could probably alternatively use
ConditionPathIsMountPoint instead, but I think I prefer the timer failing.

I also have to admit here that I am still not sure *what* I want (sorry), so I
think I'll just have stop fiddling with this for now and see how this works out
in practice.

Regardless: thoughts?

Greetings
-- 
Marc Joliet