I'm trying to get a systemd unit to fire on boot once a week. Reading up
on timer units, I can't work out how to get it to work.

This is tied up with my earlier systemd mount post - I've now got that
sorted - I've got dm-integrity to fire before fstab.

I now want to run lvm snapshot on the first boot of the weekend. Writing
a unit to do the snapshot seems pretty easy, but obviously I don't want
it firing every boot, if I stick the date in the volume name I don't
want it colliding with an earlier run the same day, etc etc.

The question really is - if I have a weekly timer fire and activate the
unit, is the activation going to survive the reboot to run on the next boot?

The problem I'm having is that all the stuff I've seen about timers says
you have two lines - activate on Saturdays, and activate on boot. Snag
is, they seem to be independent such that EITHER condition will activate
the service. As I say, I want BOTH. I don't want the service running
while the system is up and running.

Cheers,
Wol

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, Oct 1, 2021 at 3:37 PM antlists <antlists@youngman.org.uk> wrote:

I'm trying to get a systemd unit to fire on boot once a week. Reading up
on timer units, I can't work out how to get it to work.

This is tied up with my earlier systemd mount post - I've now got that
sorted - I've got dm-integrity to fire before fstab.

I now want to run lvm snapshot on the first boot of the weekend. Writing
a unit to do the snapshot seems pretty easy, but obviously I don't want
it firing every boot, if I stick the date in the volume name I don't
want it colliding with an earlier run the same day, etc etc.

The question really is - if I have a weekly timer fire and activate the
unit, is the activation going to survive the reboot to run on the next
boot?

The problem I'm having is that all the stuff I've seen about timers says
you have two lines - activate on Saturdays, and activate on boot. Snag
is, they seem to be independent such that EITHER condition will activate
the service. As I say, I want BOTH. I don't want the service running
while the system is up and running.

I'm not sure timer units have enough flexibility to do what you want.

I think it would be much simpler to have a Type=oneshot service at boot,
and the Exec= line to call a script. You can store the timestamp of the
last time it was called someplace in the filesystem (say,
/var/lib/my-script or something), and if the timestamp doesn't exists or is older than one week, the scripts executes lvm snapshot and updates the timestamp; otherwise it ends without doing anything.

The timer units are very similar to cron, and I believe what you want
cannot be done with cron either; you need special logic and state ("I'm
booting AND haven't run this in at least a week"), so a script is necessary
(I think). Luckly, systemd allows you to smartly manage your scripts and
impose dependencies on them (you need /var in my example, and you can set
it to run before starting X).

Regards.
--
Dr. Canek Peláez Valdés
Profesor de Carrera Asociado C
Departamento de Matemáticas
Facultad de Ciencias
Universidad Nacional Autónoma de México

<div dir="ltr"><div dir="ltr">On Fri, Oct 1, 2021 at 3:37 PM antlists &lt;<a href="mailto:antlists@youngman.org.uk">antlists@youngman.org.uk</a>&gt; wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;
border-left:1px solid rgb(204,204,204);padding-left:1ex">I&#39;m trying to get a systemd unit to fire on boot once a week. Reading up <br>
on timer units, I can&#39;t work out how to get it to work.<br>

This is tied up with my earlier systemd mount post - I&#39;ve now got that <br> sorted - I&#39;ve got dm-integrity to fire before fstab.<br>

I now want to run lvm snapshot on the first boot of the weekend. Writing <br>
a unit to do the snapshot seems pretty easy, but obviously I don&#39;t want <br>
it firing every boot, if I stick the date in the volume name I don&#39;t <br> want it

On 01/10/2021 22:54, Canek Peláez Valdés wrote:

On Fri, Oct 1, 2021 at 3:37 PM antlists <antlists@youngman.org.uk <mailto:antlists@youngman.org.uk>> wrote:

I think it would be much simpler to have a Type=oneshot service at boot,
and the Exec= line to call a script. You can store the timestamp of the
last time it was called someplace in the filesystem (say,
/var/lib/my-script or something), and if the timestamp doesn't exists or
is older than one week, the scripts executes lvm snapshot and updates
the timestamp; otherwise it ends without doing anything.

Ouch. Dunno if that would work. Bear in mind I'm running this BEFORE
fstab, so / is read-only ...

The timer units are very similar to cron, and I believe what you want
cannot be done with cron either; you need special logic and state ("I'm booting AND haven't run this in at least a week"), so a script is
necessary (I think). Luckly, systemd allows you to smartly manage your scripts and impose dependencies on them (you need /var in my example,
and you can set it to run before starting X).

I will have to see if the timer can set up the oneshot service, and if
it really is one shot per activation ...

Cheers,
Wol

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, Oct 1, 2021 at 5:24 PM antlists <antlists@youngman.org.uk> wrote:
[...]

Ouch. Dunno if that would work. Bear in mind I'm running this BEFORE
fstab, so / is read-only ...

You can store the timestamp in /run and then have another unit that updates
the timestamp in /var after remounting root (/) read/write. Again, you have
all the flexibility of scripts+systemd units.

I will have to see if the timer can set up the oneshot service, and if

it really is one shot per activation ...

It's one shot per activation, but the activation is set either by timer, or
by unit dependency (After= and/or Before=), AFAIU. I don't think the granularity you want is there: the timer will elapse once a week, whether
you are booting or running the system (if using timers); or it will run at boot, whether a week has passed or not (if using a normal service). I don't think you can mix and match; the precise state you want is beyond what
systemd offers (I think).

I think the simpler answer is to write a script and handle the state
yourself; but knock yourself up. It's possible I'm wrong and you can do
that with only systemd units/timers.

Regards.
[1] https://man7.org/linux/man-pages/man5/systemd.timer.5.html
--
Dr. Canek Peláez Valdés
Profesor de Carrera Asociado C
Departamento de Matemáticas
Facultad de Ciencias
Universidad Nacional Autónoma de México

<div dir="ltr"><div dir="ltr">On Fri, Oct 1, 2021 at 5:24 PM antlists &lt;<a href="mailto:antlists@youngman.org.uk">antlists@youngman.org.uk</a>&gt; wrote:<br></div><div dir="ltr">[...]</div><div class="gmail_quote"><blockquote class="gmail_quote" style="
margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Ouch. Dunno if that would work. Bear in mind I&#39;m running this BEFORE <br>
fstab, so / is read-only ...<br></blockquote><div><br></div><div>You can store the timestamp in /run and then have another unit that updates the timestamp in /var after remounting root (/) read/write. Again, you have all the flexibility of scripts+
systemd units.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I will have to see if the timer can s

On Fri, Oct 1, 2021 at 4:36 PM antlists <antlists@youngman.org.uk> wrote:

I now want to run lvm snapshot on the first boot of the weekend. Writing
a unit to do the snapshot seems pretty easy, but obviously I don't want
it firing every boot, if I stick the date in the volume name I don't
want it colliding with an earlier run the same day, etc etc.

I'm not sure a timer is a great way to do this. Offhand I'm not sure
how the persistence on those works exactly - maybe you could get it to
fire off when you want it to. However, there is another issue you're
missing.

I assume you want to wait for the snapshot to complete before you
mount local filesystems. Normally you'd just do this with a
dependency - the local filesystems get an After dependency on your
snapshot, so they don't get mounted until the snapshot is complete.
The problem is that the service that does the snapshot won't be
enabled - so the dependency will not constrain mounting the
filesystems. An After dependency on its own doesn't cause the thing
it depends on to run - it just says that IF it is going to run it has
to run first. The service that does the snapshot is going to be
started by the timer, not a target, and so at the moment the
dependencies are analyzed it won't be taken into account. That
creates a race condition, since timers do not launch their services in
any sort of synchronization with the system startup.

Now, you could set a dependency on the snapshot such that it doesn't
let filesystems be mounted while it runs, but then when it gets run it
will force all your filesystems to unmount (which is basically going
to do a clean near-shutdown of your entire system to whatever degree
it has started up), then do the snapshot, then remount everything and
restart it all. That isn't what you want either.

I think the cleanest approach is just make the snapshot a regular
service and enable it and set up the dependencies so that it has to
complete before local filesystems are mounted. Then all you need to
do is put logic in that service that turns it into a no-op if there is
a recent enough snapshot already.

Timers are really useful for stuff that is asynchronous, whether
time-based or not. They're not really good for anything synchronous
with the boot process, unless there is some magic to this that I'm
unaware of.

--
Rich

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)