getTime.sh not working at startup

[Stefann]

Hi,
I hope I do this right but anyway...

When I startup tiny core the time is not synced.
running getTime.sh as user also does not sync it
running with sudo does

What I did:

Code: [Select]

Give clock a 3minute error, than REBOOT....
tc@hp510:~$ sudo reboot

==================

after reboot:
tc@hp510:~$ date
Fri May  2 13:20:09 CEST 2025.    //this is wrong
tc@hp510:~$ getTime.sh
tc@hp510:~$ date
Fri May  2 13:20:21 CEST 2025.    //still wrong
tc@hp510:~$ sudo getTime.sh
tc@hp510:~$ date
Fri May  2 11:18:06 CEST 2025.   //OK now
tc@hp510:~$
For reference, my extlinux.conf:

Code: [Select]

DEFAULT gui16

LABEL gui16
KERNEL /tce/boot/vmlinuz16
INITRD /tce/boot/core16.gz
APPEND quiet  host=hp510 tz=CET-1CEST,M3.5.0,M10.5.0/3 waitusb=5:UUID="ab0b387d-7533-4e69-a8ac-ee5ab733c5f7" tce=UUID="ab0b387d-7533-4e69-a8ac-ee5ab733c5f7"
tested on TC16
also tested on TC15 >> same behaviour

In itself this is not a big deal, I can easily add sudo getTime.sh to boot local.sh
Just want to understand whether I do something wrong

[Paul_123]

It runs automatically if you are using dhcp for your network.  But it will timeout after 60s if the network does not have an address.

If you use a static network configuration, the you need to manage it all manually.

[Stefann]

As far as I understand (I'm not a guru) I'm using dhcp:
- I'm assigning it a fixed address from my router but I consider that dhcp (right?)
- I have no config files in .filetool.lst, only network related is "usr/local/etc/httpd/httpd.conf" but that is apache only I think.
- also not other files in /opt or /opt (but I may overlook something)

And I'm booting below 60seconds:
- I'm booting in 39seconds towards a ssh prompt

So I feel "it should have worked" out of the box.
Note: running 32bit version on 64bit Via Eden cpu

Any "tip" on how to debug this further?
> like "where is it called" such that I can potentially check a bit what happens.

mmmh... maybe I should modify the getTime.sh such that it creates a logging

[Paul_123]

It’s not the boot time, it’s how long it takes for you to get a network address. ntp is also not instantaneous when syncing a time.

 It’s called from /etc/init.d/tc-config. (Near the end). /etc/inti.d/settime.sh is what gets called.

[Stefann]

thanks,
I'll check what happens.
ehh... if I got an ssh connection from a remote computer 39seconds after start, the network connection should also have been there within that 39seconds.

Anyway... no worry... I'll figure that out.
thanks for pointing me into a direction
(expect it to take a day or so before I have an update)

[Rich]

Hi Stefann
If you want a way to log whether your network is up or down:

Code: [Select]

tc@E310:~$ echo "$(date | tr '\n' ' ' && ifconfig | grep -q Bcast && echo Up || echo Down)"
Fri May  2 09:30:33 UTC 2025 Up
tc@E310:~$If the network was down, it would have printed:

Code: [Select]

Fri May  2 09:30:33 UTC 2025 Down
Just place something like this where ever you want to test the networks status:

Code: [Select]

echo "$(date | tr '\n' ' ' && ifconfig | grep -q Bcast && echo Up || echo Down)" >> /tmp/Network.log

[Paul_123]

Since he can ssh in,  I suspect the problem is with name resolution of the ntp server, or ntp just being slow.

[Rich]

Hi Paul_123

Since he can ssh in, ...

You're probably right, I just wanted to offer a simple command for
logging network status.

[Stefann]

1st: thanks Rich for the code-snippets, I'm not good at shell language so it gave a me a toolbox. Thnaks.

With that said...... I did some testing.
My main conclusion: time will only be updated at boot if clock battery is dead.

What i did:

Test1: set date to 1jan 2010 and try to run getTime.sh with sudo >> succeeds
I did not expect that, if i understand man-page correct it needs option -g to succeed with offset above 1000secs
But anyways.... this proofs getTime.sh always updates time even if it's a really big delta

Code: [Select]

tc@hp510:~$ sudo date 010101012010
Fri Jan  1 01:01:00 CET 2010
tc@hp510:~$ date
Fri Jan  1 01:01:03 CET 2010
tc@hp510:~$ sudo getTime.sh
tc@hp510:~$ date
Sat May  3 08:01:27 CEST 2025
Test2: set date to 1jan 2010 and try to run settime.sh with sudo >> succeeds
Note: command took about 3seconds to run (not precise, just counted out loudly)

Code: [Select]

tc@hp510:/etc/init.d$ sudo date 010101012010
Fri Jan  1 01:01:00 CET 2010
tc@hp510:/etc/init.d$ date
Fri Jan  1 01:01:03 CET 2010
tc@hp510:/etc/init.d$ sudo ./settime.sh
tc@hp510:/etc/init.d$ date
Sat May  3 08:06:01 CEST 2025
Test3: set date to 1jan 2016 and try to run settime.sh with sudo >> fails
No update (command now takes only a split second)

Code: [Select]

tc@hp510:/etc/init.d$ sudo date 010101012016
Fri Jan  1 01:01:00 CET 2016
tc@hp510:/etc/init.d$ date
Fri Jan  1 01:01:02 CET 2016
tc@hp510:/etc/init.d$ sudo ./settime.sh
tc@hp510:/etc/init.d$ date
Fri Jan  1 01:01:12 CET 2016
Test4: set date to 1jan 2010 and reboot >> succeeds
Alike test 1 set date to 1jan 2010, reboot.
now time is properly updated.

Analysis/rootcause:
below codesnippet of settime.sh shows it checks whether current date is later than 2015 and breaks without setting date if it is:

Code: [Select]

        XXX=$(/bin/date -I)
        XXX=${XXX:0:4}

        if [ "$XXX" -ge "2015" ];
        then
            break
        fi       
This effectively means:
- if clock battery is dead there will be a time update.
- if clock battery is "ok" there will not be a time update.

Whether this is wanted or unwanted behavior is open for discussion.
To be honest, as the update adds 3 seconds to the boot-time (or is it done in the background???) I'm totally ok that it does not.
This implies however that i will need to call sudo getTime.sh regularly with a crontab.

Note: I hope i did everything correct
       
for completeness & easy reference: full content of settime.sh

Code: [Select]

tc@hp510:/etc/init.d$ cat settime.sh
#!/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

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

        if [ "$XXX" -ge "2015" ];
        then
            break
        fi

        if [ $CNT -gt 10 ];
        then
            /usr/bin/getTime.sh
            if [ $NRT -gt 5 ];
            then
                break
            fi
            CNT=0
            NRT=$((NRT+1))
        fi

    CNT=$((CNT+1))
    sleep 1
    done
fi


[Stefann]

update......
no... its a bit different.

yes, test1,test2,test3 are as I said.
however test4 is slightly different....

test4/redo: set clock to 2010 and reboot >> clock is updated to 2025 BUT has 2h03m offset

Code: [Select]

tc@hp510:~$ sudo getTime.sh
tc@hp510:~$ date
Sat May  3 10:17:06 CEST 2025   // note: this is correct
tc@hp510:~$ sudo date 010101012010
Fri Jan  1 01:01:00 CET 2010
tc@hp510:~$ date
Fri Jan  1 01:01:03 CET 2010
tc@hp510:~$ sudo reboot

.........wait........

tc@hp510:~$ date
Sat May  3 12:23:55 CEST 2025 // this is roughly 2h03m wrong
tc@hp510:~$ sudo getTime.sh
tc@hp510:~$ date
Sat May  3 12:24:03 CEST 2025  // even after time update that succeeded earlier still wrong
tc@hp510:~$ sudo getTime.sh
tc@hp510:~$ date
Sat May  3 10:21:18 CEST 2025 // after an other time update it is correct now
tc@hp510:~$

test5, set clock to 2016 and reboot >> strangely enough, time is updated () also with 2h03m offset
strange, so settime.sh I demonstrated to NOT update with year=2016 but now it updates
And again 2h03m wrong
and again time only corrects after second getTime.sh call

Code: [Select]

tc@hp510:~$ sudo date 010101012016
Fri Jan  1 01:01:00 CET 2016
tc@hp510:~$ date
Fri Jan  1 01:01:01 CET 2016
tc@hp510:~$ sudo reboot

.........wait........

tc@hp510:~$ date
Sat May  3 12:29:11 CEST 2025  // again... roughly 2h03m wrong
tc@hp510:~$ sudo getTime.sh
tc@hp510:~$ date
Sat May  3 12:29:23 CEST 2025 // again... even after time update that succeeded earlier still wrong
tc@hp510:~$ sudo getTime.sh
tc@hp510:~$ date
Sat May  3 10:26:20 CEST 2025 // again... after an other time update it is correct now
tc@hp510:~$

I post this now as "intermediate status"
I will think about how to move on this further.
I guess /etc/init.d/tc-config calls even other stuff.

I will look further but "hints" are welcome

[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: [Select]

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:~$
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: [Select]

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
test7; reboot from correct time >> wanted to catch logging in time.tx but no logging is generated

Code: [Select]

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
..........


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: [Select]

# 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 &
fiThis 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: [Select]

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

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: [Select]

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
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: [Select]

hwclock --systohc --utc
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: [Select]

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