| 1 |
On Fri, Oct 1, 2021 at 5:24 PM antlists <antlists@××××××××××××.uk> wrote: |
| 2 |
[...] |
| 3 |
|
| 4 |
> Ouch. Dunno if that would work. Bear in mind I'm running this BEFORE |
| 5 |
> fstab, so / is read-only ... |
| 6 |
> |
| 7 |
|
| 8 |
You can store the timestamp in /run and then have another unit that updates |
| 9 |
the timestamp in /var after remounting root (/) read/write. Again, you have |
| 10 |
all the flexibility of scripts+systemd units. |
| 11 |
|
| 12 |
I will have to see if the timer can set up the oneshot service, and if |
| 13 |
> it really is one shot per activation ... |
| 14 |
> |
| 15 |
|
| 16 |
It's one shot per activation, but the activation is set either by timer, or |
| 17 |
by unit dependency (After= and/or Before=), AFAIU. I don't think the |
| 18 |
granularity you want is there: the timer will elapse once a week, whether |
| 19 |
you are booting or running the system (if using timers); or it will run at |
| 20 |
boot, whether a week has passed or not (if using a normal service). I don't |
| 21 |
think you can mix and match; the precise state you want is beyond what |
| 22 |
systemd offers (I think). |
| 23 |
|
| 24 |
I think the simpler answer is to write a script and handle the state |
| 25 |
yourself; but knock yourself up. It's possible I'm wrong and you can do |
| 26 |
that with only systemd units/timers. |
| 27 |
|
| 28 |
Regards. |
| 29 |
[1] https://man7.org/linux/man-pages/man5/systemd.timer.5.html |
| 30 |
-- |
| 31 |
Dr. Canek Peláez Valdés |
| 32 |
Profesor de Carrera Asociado C |
| 33 |
Departamento de Matemáticas |
| 34 |
Facultad de Ciencias |
| 35 |
Universidad Nacional Autónoma de México |
Archives