[systemd-devel] Calendar Timers: setting system clock may trigger jobs from the past

[Lennart Poettering]

On Mon, 04.08.14 12:50, Peter Mattern (matternp at arcor.de) wrote:

> Hello.
> 
> If a *.timer unit's timestamp as stated by OnCalendar is in the past
> and the actual system time is even before that timestamp the *.timer
> gets activated when the system clock gets set.

Which appears like the right thing to do I must say.

> This frequently happens on embedded devices which get their system
> time set during boot by 'ntpd -qg' and the like due to lack of an
> RTC. An import drawback is that *.timer units cannot be used to shut
> down or reboot the system in a context like this, imho.

This sounds like you should make sure your one-time ntp service should
be ordered before time-sync.target and your .timer unit after it, so
that it it doesn't get scheduled before the time is set correctly (in
fact, on the TODO list there's an item, to make sure that we
implicitly order all OnCalendar units after time-sync.target, but in the
meantime you can do that manually). 

Also note that you can use systemd-timesyncd which implements SNTP
but also saves/restores the RTC to disk across reboots. This has the
benefit that time at least monotonically progresses, even though at boot
until NTP is synced you won't get correct time. It is by default ordered
before time-sync.target, hence you'd only need the
After=time-sync.target in your .timer units then...

Lennart

-- 
Lennart Poettering, Red Hat