You're right, I misunderstood the purpose the the Requires directive. Thanks for pointing this out, I am seeing the expected behavior in my script after removing it.
Alden
On Mon, Mar 4, 2019 at 1:43 PM Andrei Borzenkov <arvidjaar@xxxxxxxxx> wrote:
04.03.2019 21:19, Alden Page пишет:
> Hi systemd team,
>
> I'm having some trouble understanding the behavior of a systemd timer I've
> set up in systemd version 219. I have a task that I want to run once per
> week on Sundays at 3:00am UTC. However, as soon as I do `systemctl start
> my_timer.timer`, the task starts no matter what time it is. This is a
That is what you told it to do.
> problem for me, because that means that my timer starts every single time I
> recreate my server's virtual machine. After the initial erroneously
> scheduled job has completed successfully, the timer starts behaving
> correctly and runs on Sundays at 3:00am UTC.
>
> Here is how I've set up my timers. This is an excerpt from the script I use
> to bootstrap my VMs:
>
> # Schedule weekly ingest of new data
> cat << EOF > /etc/systemd/system/ingest_upstream.service
> [Unit]
> Description=Load and index image data from upstream.
> [Service]
> ExecStart=/usr/bin/curl -XPOST localhost:8001/task -H "Content-Type:
> application/json" -d '{"model": "image", "action": "INGEST_UPSTREAM"}'
> EOF
>
> cat << EOF > /etc/systemd/system/ingest_upstream.timer
> [Unit]
> Description=Ingest data from upstream every Sunday at 8:00am EST (3:00am
> UTC).
> Requires=ingest_upstream.service
>
Requires means - when ingest_upstream.timer is started (activated) also
start (activate) units listed here. Which is exactly what happens.
> [Timer]
> _OnCalendar_=Sun *-*-* 3:00:00
> Unit=ingest_upstream.service
>
> [Install]
> WantedBy=timers.target
> EOF
> systemctl start ingest_upstream.timer
>
> After `systemctl start`, shouldn't it wait until the next OnCalendar
> interval has passed, particularly since `Persistent=...` is not set?
>
It (presumably ingest_upstream.timer) does wait; your service is not
activated by timer but by basic systemd unit dependency.
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
_______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel
