We need to tell hwclock with -u commandline option, that we would like
to keep our RTC clock in UTC timezone. Linux kernel expects RTC in UTC
timezone anyway.
In current state of things, we don't tell hwclock to load/store time
from/to RTC in UTC timezone so it uses the timezone from the system
time. If it's set to different timezone then UTC, sysfixtime is going to
screw the time in RTC.
I've following in the setup script:
uci set system.@system[0].timezone='CET-1CEST,M3.5.0,M10.5.0/3'
uci set system.@system[0].zonename='Europe/Prague'
I've this RTC setup (rtc1 is RTC on i.MX6 SoC, rtc0 is battery backed RTC mcp7941x):
rtc-ds1307 3-006f: rtc core: registered mcp7941x as rtc0
snvs_rtc 20cc000.snvs:snvs-rtc-lp: rtc core: registered 20cc000.snvs:snvs-r as rtc1
Then we can experience following (current time is 10:15am):
$ date
Fri Oct 21 10:15:07 CEST 2016
$ hwclock -r -f /dev/rtc0
Fri Oct 21 08:14:46 2016 0.000000 seconds
$ hwclock -u -r -f /dev/rtc0
Fri Oct 21 10:14:46 2016 0.000000 seconds
And after current broken sysfixtime:
$ /etc/init.d/sysfixtime stop
$ date
Fri Oct 21 10:15:25 CEST 2016
$ hwclock -r -f /dev/rtc0
Fri Oct 21 10:15:31 2016 0.000000 seconds
Now we've time in our battery backed RTC in CEST timezone instead of
UTC. Then once again, but with this patch applied to sysfixtime, where
hwclock is using correctly the -u parameter:
$ /etc/init.d/sysfixtime stop
$ date
Fri Oct 21 10:15:53 CEST 2016
$ hwclock -r -f /dev/rtc0
Fri Oct 21 08:15:55 2016 0.000000 seconds
Signed-off-by: Petr Štetiar <ynezz@true.cz>
Acked-by: Jo-Philipp Wich <jo@mein.io>
dnsmasq's dnssec time checking method now uses a ntp hotplug mechanism,
therefore dnsmasq.time is redudant and no longer needs to be explicitly
excluded from sysfixtime.
Signed-off-by: Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk>
Typo, missing space before ] in previous commit caused shell syntax
failure and incorrect restoration of time.
Signed-off-by: Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk>
dnsmasq maintains dnsmasq.time across reboots and uses it as a means of
determining if current time is good enough to validate dnssec time
stamps. By including /etc/dnsmasq.time as a time source for sysfixtime,
the mechanism was effectively defeated because time was set to the
last time that dnsmasq considered current even though that time is in
the past. Since that time is out of date, dns(sec) resolution would
fail thus defeating any ntp based mechanisms for setting the clock
correctly.
In theory the process is defeated by any files in /etc that are newer
than /etc/dnsmasq.time however dnsmasq now updates the file's timestamp
on process TERM so hopefully /etc/dnsmasq.time is the latest file
timestamp in /etc as part of LEDE shutdown/reboot.
Either way, including /etc/dnsmasq.time as a time source for
sysfixtime is not helpful.
Signed-off-by: Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk>
dnsmasq maintains dnsmasq.time across reboots and uses it as a means of
determining if current time is good enough to validate dnssec time
stamps. By including /etc/dnsmasq.time as a time source for sysfixtime,
the mechanism was effectively defeated because time was set to the
last time that dnsmasq considered current even though that time is in
the past. Since that time is out of date, dns(sec) resolution would
fail thus defeating any ntp based mechanisms for setting the clock
correctly.
In theory the process is defeated by any files in /etc that are newer
than /etc/dnsmasq.time however dnsmasq now updates the file's timestamp
on process TERM so hopefully /etc/dnsmasq.time is the latest file
timestamp in /etc as part of LEDE shutdown/reboot.
Either way, including /etc/dnsmasq.time as a time source for
sysfixtime is not helpful.
On systems that have an RTC prefer it to the file-based time fixup (i.e.
use hwclock when there is a permanent clock instead of the faked up time
logic that is needed when there is not RTC).
We can't rely on hctosys kernel feature either as we're usually using
RTC as kernel modules which are usually being loaded after hctosys was
run, leading in the following error:
hctosys: unable to open rtc device (rtc0)
Signed-off-by: Daniel Dickinson <openwrt@daniel.thecshore.com>
Signed-off-by: Petr Štetiar <ynezz@true.cz>
SVN-Revision: 48661
Seems like the reverse order relies on GNU specific getopt hackery which
musl does not replicate
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
SVN-Revision: 41045
Simply scan for the most recent file in /etc and set
system time to this file modification time if it's in the future
It allow some time dependent program to work immediatly
without waiting for ntpd to sync
v1: v2: bad approach
v3: simply scan /etc, thanks to Bastian Bittorf for the idea
v4: use sort -n, thanks to Catalin Patulea
v5: use [] instead of [[]], thanks to Andreas Mohr
v6: use openwrt style, thanks to Bastian Bittorf
Signed-off-by: Etienne CHAMPETIER <etienne.champetier@free.fr>
SVN-Revision: 39422
Petr Štetiar
Kevin Darbyshire-Bryant
Jo-Philipp Wich
John Crispin
Felix Fietkau
Jo-Philipp Wich