1. Forum
  2. Usenet
  3. LINUX.GENTOO.USER

  • [gentoo-user] systemd boot timer

    From antlists@21:1/5 to All on Fri Oct 1 22:40:02 2021
    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)
  • From =?UTF-8?B?Q2FuZWsgUGVsw6FleiBWYWxkw@21:1/5 to [email protected] on Sat Oct 2 00:00:02 2021
    On Fri, Oct 1, 2021 at 3:37 PM antlists <[email protected]> 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:[email protected]">[email protected]</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
  • From antlists@21:1/5 to All on Sat Oct 2 00:30:01 2021
    On 01/10/2021 22:54, Canek Peláez Valdés wrote:
    On Fri, Oct 1, 2021 at 3:37 PM antlists <[email protected] <mailto:[email protected]>> 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)
  • From =?UTF-8?B?Q2FuZWsgUGVsw6FleiBWYWxkw@21:1/5 to [email protected] on Sat Oct 2 00:50:01 2021
    On Fri, Oct 1, 2021 at 5:24 PM antlists <[email protected]> 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:[email protected]">[email protected]</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
  • From Rich Freeman@21:1/5 to [email protected] on Sat Oct 2 02:40:01 2021
    On Fri, Oct 1, 2021 at 4:36 PM antlists <[email protected]> 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)