ExternalVendorCode/openwrt
1
0
Fork 0
mirror of https://github.com/openwrt/openwrt.git synced 2024-12-22 06:57:57 +00:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity
aca39acedf
openwrt/package/base-files/files/etc/init.d/sysfixtime

35 lines
662 B
Plaintext
Raw Normal View History

Add sysfixtime init script, replacement of luci_fixtime 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
2014-01-29 13:17:03 +00:00
#!/bin/sh /etc/rc.common
# Copyright (C) 2013-2014 OpenWrt.org
START=00
base-files: For sysfixtime use hwclock if RTC available 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
2016-02-08 08:25:53 +00:00
STOP=90
RTC_DEV=/dev/rtc0
HWCLOCK=/sbin/hwclock
Add sysfixtime init script, replacement of luci_fixtime 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
2014-01-29 13:17:03 +00:00
boot() {
base-files: For sysfixtime use hwclock if RTC available 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
2016-02-08 08:25:53 +00:00
start && exit 0
base-files: sysfixtime exclude dnsmasq.time 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>
2016-05-05 11:34:49 +00:00
local maxtime="$(maxtime)"
Add sysfixtime init script, replacement of luci_fixtime 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
2014-01-29 13:17:03 +00:00
local curtime="$(date +%s)"
base-files: removes logging Since logd haven't started at this point, logging does not work. Signed-off-by: Nuno Goncalves <nunojpg@gmail.com> SVN-Revision: 40904
2014-06-02 12:42:37 +00:00
[ $curtime -lt $maxtime ] && date -s @$maxtime
Add sysfixtime init script, replacement of luci_fixtime 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
2014-01-29 13:17:03 +00:00
}
base-files: For sysfixtime use hwclock if RTC available 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
2016-02-08 08:25:53 +00:00
start() {
base-files: sysfixtime: Keep RTC time in UTC timezone 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>
2016-10-31 10:50:09 +00:00
[ -e "$RTC_DEV" ] && [ -e "$HWCLOCK" ] && $HWCLOCK -s -u -f $RTC_DEV
base-files: For sysfixtime use hwclock if RTC available 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
2016-02-08 08:25:53 +00:00
}
stop() {
base-files: sysfixtime: Keep RTC time in UTC timezone 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>
2016-10-31 10:50:09 +00:00
[ -e "$RTC_DEV" ] && [ -e "$HWCLOCK" ] && $HWCLOCK -w -u -f $RTC_DEV && \
base-files: For sysfixtime use hwclock if RTC available 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
2016-02-08 08:25:53 +00:00
logger -t sysfixtime "saved '$(date)' to $RTC_DEV"
}
base-files: sysfixtime exclude dnsmasq.time 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>
2016-05-05 11:34:49 +00:00
maxtime() {
local file newest
base-files: sysfixtime no longer exclude dnsmasq.time 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>
2016-06-16 09:50:36 +00:00
for file in $( find /etc -type f ) ; do
base-files: sysfixtime typo in exclude dnsmasq.time 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>
2016-05-19 15:57:19 +00:00
[ -z "$newest" -o "$newest" -ot "$file" ] && newest=$file
base-files: sysfixtime exclude dnsmasq.time 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>
2016-05-05 11:34:49 +00:00
done
[ "$newest" ] && date -r "$newest" +%s
}
Reference in New Issue Copy Permalink