getTime.sh not working at startup

Tiny Core Base > TCB Bugs

<< < (3/5) > >>

Stefann:
test6, reboot on other computer I have from correct time >> 8minute offset after reboot
note: this computer is much slower takes much more time to reboot
note: this is actually my production system that runs my homecontrol system, normally donot like to test on it.

--- Code: ---tc@huis:/krubo/work$ date
Sat May 3 10:43:05 CEST 2025 // this is correct time
tc@huis:/krubo/work$ sudo reboot

....wait....

tc@huis:~$ date
Sat May 3 10:54:39 CEST 2025 // this is about 8minutes wrong
tc@huis:~$ sudo getTime.sh
tc@huis:~$ date
Sat May 3 10:46:33 CEST 2025 // correct after 1x sudo getTime.sh
tc@huis:~$
--- End code ---

back to my hp510 computer
note, this is a hp510 thin client, I use that as my staging system

modified settime.sh to add some logging.
included it in .filetool.sh

--- Code: ---do
[ $((CNT++)) -gt 60 ] && break || sleep 1
done
echo "end ifconfig check" >> /tmp/time.txt
echo $CNT >> /tmp/time.txt

if [ $CNT -le 60 ]
then
CNT=9999
NRT=0
while sleep 0
do
XXX=$(/bin/date -I)
XXX=${XXX:0:4}
echo $XXX >> /tmp/time.txt
--- End code ---

test7; reboot from correct time >> wanted to catch logging in time.tx but no logging is generated

--- Code: ---tc@hp510:~$ date
Sat May 3 11:13:56 CEST 2025 //this is correct time
tc@hp510:~$ sudo reboot

.... wait .....

tc@hp510:~$ date
Sat May 3 13:19:16 CEST 2025 //again 2h03m wrong
tc@hp510:~$ sudo getTime.sh
tc@hp510:~$ date
Sat May 3 13:19:28 CEST 2025 //again still wrong after 1x getTime.sh
tc@hp510:~$ sudo getTime.sh
tc@hp510:~$ date
Sat May 3 11:16:25 CEST 2025 //correct after 2x getTime.sh
tc@hp510:~$ cd /tmp
tc@hp510:/tmp$ ls
aberr appserr k5_skip tce/ tcloop/ wm_errors

//????? no time.txt logfile?????

tc@hp510:/tmp$ cat /etc/init.d/settime.sh. //check that indeed modified settime.sh survived the reboot >> yes it did
#!/bin/sh
# (c) Robert Shingledecker 2012
# Bela Markus 2015

# Wait for network to come up and then set time

CNT=0
until ifconfig | grep -q Bcast
do
[ $((CNT++)) -gt 60 ] && break || sleep 1
done
echo "end ifconfig check" >> /tmp/time.txt
echo $CNT >> /tmp/time.txt

if [ $CNT -le 60 ]
then
CNT=9999
NRT=0
while sleep 0
do
XXX=$(/bin/date -I)
XXX=${XXX:0:4}
echo $XXX >> /tmp/time.txt
..........

--- End code ---

ok... at this point a give it some rest
maybe later
maybe tomorrow
things need to sink in a bit and I have some other obligations.

Stefann:
ok...
I checked /etc/init.d/tc-config. (Near the end) and gave it a careful read > thanks Paul_123 for guiding me there

tc-config code snippet:

--- Code: ---# After restore items
if [ -n "$NODHCP" ]; then
echo "${GREEN}Skipping DHCP broadcast/network detection as requested on boot commandline.${NORMAL}"
else
[ -z "$DHCP_RAN" ] && /etc/init.d/dhcp.sh &
[ -z "$NORTC" ] || /etc/init.d/settime.sh &
fi
--- End code ---
This means that settime.sh will only be called IF nortc bootcode is set!
(mhh... to some point this is funny, that is actually the title of this thread :-) )

so... I included nortc bootcode...

test8, reboot from 2020 with nortc bootcode >> confirm settime.sh is executed; getTime.sh is not called
It becomes understandable:
- with nortc bootcode indeed settime.sh is called
- this takes 6 seconds to "wait for ifconfig >> which means that I "not really like to include this" in my boot sequence
- before calling getTime.sh it checks /bin/date -I, that returns a "2025" and resultantly getTime.sh is NOT called as was already identified in test3.

--- Code: ---tc@hp510:~$ sudo date 010101012010
Fri Jan 1 01:01:00 CET 2010
tc@hp510:~$ date
Fri Jan 1 01:01:02 CET 2010. //so indeed set system to 2010, before the 2015 check
tc@hp510:~$ sudo reboot

.....wait....

tc@hp510:~$ date
Sat May 3 13:52:29 CEST 2025. //so time is updated to 2h03m wrong version
tc@hp510:~$ cd /tmp
tc@hp510:/tmp$ ls -l time.txt
-rw-r--r-- 1 root root 26 May 3 13:51 time.txt //yes, logging has been written now, so settime.sh has been called
tc@hp510:/tmp$ cat time.txt
end ifconfig check
6 //so ifconfig is detected after 6 loops of 1 second
2025 //so bin/date command gave 2025 year. and that means that getTime.sh is not called

--- End code ---

What I think happens....
- setTime.sh sets the systemclock but NOT the HW clock.
- so on my one system I get 2h03m offset form HW clock at boot; on my other system I get 8min offset from HWclock.

text9, check HW clock >> indeed looks like hwclock is the bad guy

--- Code: ---tc@huis:~$ sudo getTime.sh // make sure to have correct time
tc@huis:~$ date
Sat May 3 12:15:37 CEST 2025. // yes time is correct
tc@huis:~$ sudo hwclock --systohc //sync hwclock
tc@huis:~$ hwclock
Sat May 3 12:15:50 2025 0.000000 seconds. //hwclock is correct
tc@huis:~$sudo reboot

.... wait .....

tc@hp510:~$ date
Sat May 3 14:17:47 CEST 2025 //this seems 2h off
tc@hp510:~$ date
Sat May 3 14:18:12 CEST 2025
tc@hp510:~$ sudo getTime.sh
tc@hp510:~$ date
Sat May 3 12:18:20 CEST 2025. //so yes, it was 2hr off.. but... no longer 2hr03mins, I guess this is caused by timezone thing
tc@huis:~$sudo reboot. //try new reboot

.....wait....

tc@hp510:~$ hwclock
Sat May 3 12:22:12 2025 0.000000 seconds
tc@hp510:~$ date
Sat May 3 14:22:15 CEST 2025 // so yes, hwclock is correct, system time is not
--- End code ---

So...
- unless nortc bootcode is set no time sync is done at all
- with nortc bootcode settime.sh is called but before calling getTime.sh the hardware clock is checked and unless it reports before 2015 getTime.sh is not called
- using "sudo hwclock --systohc" syncs the hw clock but does not properly take timezone into account >> I guess this is simply intended behaviour, just my ignorance on this.

For now I give it some rest.
things needs to sink in

Stefann:
looks like I need to use:

--- Code: ---hwclock --systohc --utc
--- End code ---

Which means.. overall conclusion (in case you got lost):
- if no nortc bootcode is set the clock will be updated from hw clock and NOT read from internet, settime.sh is not called, getTime.sh is also not called
- if nortc bootcode is set AND if dhcp is used, settime.sh is called.
- settime.sh takes (at least at my system) 6 seconds to wait for ifconfig, so this delays your boot (but it is called with "&" so nonblocking)
- settime reads hw lock and only calls getTime.sh IF hwclock reports before 2015. --> effectively: only with dead battery.

In practice this means that almost always you boot with hwclock without sync with internet.

In principle this works for me. I like that bootcycle is not unnecessary long.
It does however mean that some time-sync method needs to be there.
This can be by a regular crontab call of getTime.sh but:
- this does not set the hardware clock
- it does not have a safety mechanism for "unrealistic big offsets", the "must-be-in 1000sec window" behaviour is not present (maybe because of -q option, but that I don't know)
- in fact..... probably run ntpd daemon "the way it is intended" and not use the -q option, and sync hw clock weekly with a crontab

Paul_123:
I’m a piCore guy, which uses nortc by default.

When I last checked ntpd will sync the hwclock if running as a daemon.

Stefann:
Well.... after many tests I figured it all out. Conclusion towards those also wanting to keep time uptodate.......
- and thanks Paul_123 for pointing me into directions including mentioning ntpd syncs hwclock

1/ bootoption nortc ONLY updates time from internet if no hw clock is present or functional.
- so it syncs to internet for RPI that donot have hw clock.
- it does NOT sync to internet for most X86 boards with functional hw clock.
- so "nortc" should be read as "no rtc present" (and not as "donot use rtc").
- supported by tests in all earlier posts

2/ to keep time current: add "sudo ntpd -p pool.ntp.org" to bootlocal.sh.

3/ Note that FAQ is outdated on this
- http://tinycorelinux.net/faq.html#bootcodes mentions "settime" bootcode which does no longer exist, it does not mention "nortc" bootcode

ntpd tested
- ntpd corrects a time offset
- ntpd syncs hwclock
- resource use is very minimal (mostly 0% when using top on old hp510 thin x86 client)

--- Code: ---tc@hp510:~$ date //this time is same as time on laptop
Sun May 4 07:39:44 CEST 2025
tc@hp510:~$ sudo date 05040730 //set clock 10mins back
Sun May 4 07:30:00 CEST 2025
tc@hp510:~$ date //confirm, its 10min back
Sun May 4 07:30:03 CEST 2025
tc@hp510:~$ sudo hwclock --systohc --utc //sync hwclock to system clock
tc@hp510:~$ hwclock
Sun May 4 05:31:10 2025 0.000000 seconds //confirm hwclock is 2hrs earlier which is correct utc
tc@hp510:~$ date
Sun May 4 07:31:21 CEST 2025 //confirm systemtime is still in same ballpark, it's still 10mins off
tc@hp510:~$ sudo ntpd -p pool.ntp.org //start ntpd syncing

--- wait ----

tc@hp510:~$ date //confirm with clock of laptop, ntpd has succesfully synced time
Sun May 4 07:55:43 CEST 2025
tc@hp510:~$ hwclock //hwclock is now 10min behind system time, so ntpd did not (yet) sync hwclock
Sun May 4 05:45:27 2025 0.000000 seconds

--- wait ----

tc@hp510:~$ hwclock
Sun May 4 06:07:14 2025 0.000000 seconds
tc@hp510:~$ date
Sun May 4 08:17:52 CEST 2025 //hwclock still 10 minutes behind system time

--- wait ----

tc@hp510:~$ hwclock
Sun May 4 06:39:49 2025 0.000000 seconds
tc@hp510:~$ date
Sun May 4 08:39:51 CEST 2025 //hwclock is synced to system time
--- End code ---

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version