TC9.0 /etc/init.d/settime.sh broken

[y_satou70]

Just found this issue while I replace my box's coin battery on motherboard....
/etc/init.d/settime.sh is failed to set time due to following code:

Code: [Select]

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

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

not sure why this logic is implemented here, but due to this code, this script do nothing since 2015...

I checked both x86 and x86_64, both distribution core.gz / corepure64.gz has this bug.

[Greg Erskine]

hi y_satou70,

I "think" if the code was really broken someone would have noticed by now. 

My "guess" is it is testing that the time is not epoch therefore the time has been set by a rtc. If time set by rtc then don't run ntp. The year 2015 was probably chosen as it was the year the fix was added.

regards
Greg

[curaga]

Yes, the logic works if your board was manufactured before 2015 and so sets its date to an epoch before that. Updating to 2018.

[y_satou70]

oh wait, does it mean if system board 's clock has any timestamp 2018 then it does not do any set clock action ?
I think if boot option has "ntpserver=...." entry, it should pull current time from ntpserver and set it at booting regardless what time currently system board has.
And if it's expected that the time is set from RTC and that's good enough, then that system just need to omit "ntpserver=...." entry on boot option.

[curaga]

Yes. The current edition of settime.sh was written by Bela for rpi boards, which do not have a RTC. It also works for boards whose battery has run out.

Would you like to send a patch?

[y_satou70]

not really as the patch, but simply nuke year check should be sufficient.

Code: [Select]

box:/etc/init.d$ diff settime.sh.orig settime.sh
--- settime.sh.orig
+++ settime.sh
@@ -16,14 +16,6 @@
     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
box:/etc/init.d$


[curaga]

I believe that would cause issues on rpi with separate rtc. Those boot somewhat slow, and their users don't want the additional time taken by this if they already have a rtc set up. So conflicting requirements somewhat.

[y_satou70]

I think that is the reason why we now have "nortc" in boot option, so those devices just need to set it.

in current 9.x code /etc/init.d/tc-config:

Code: [Select]

echo -n "${BLUE}Checking boot options...${NORMAL}"
for i in `cat /proc/cmdline`; do
case $i in
*)
case $i in
nortc) NORTC=1 ;;
esac
;;
esac
done

    ....

if [ -n "$NORTC" ]; then
echo "${BLUE}Skipping rtc as requested from the boot command line.${NORMAL}"
fi

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

so the correct approach for this issue is,

• if using no RTC hardware, simply need to set "nortc" in option - then it skips clock sync (regardless "ntpserver" is set in option or not.)
• if "ntpserver" is set then let OS/Kernel sync with specified NTP server - regardless RTC's year info.

[curaga]

They do want the correct time, booting with nortc leaves the time as the epoch...

[y_satou70]

Hm, I think even in current code, the case

> ... cause issues on rpi with separate rtc. Those boot somewhat slow, and their users don't want the additional time taken by this if they already have a rtc set up.

does not handle like

> They do want the correct time, booting with nortc leaves the time as the epoch...

Because, even using RPi with separate slow RTC, if they do not set "nortc", it just wait until RTC device becomes available anyway.

As in current code, if "nortc" is *not* set then, we have eternal loop until /dev/rtc0 becomes available:

Code: [Select]

if [ -n "$NORTC" ]; then
echo "${BLUE}Skipping rtc as requested from the boot command line.${NORMAL}"
else
while [ ! -e /dev/rtc0 ]; do usleep 50000; done
if [ -n "$NOUTC" ]; then
/sbin/hwclock -l -s &
else
/sbin/hwclock -u -s &
fi
fi

so if they want to speed up the boot then they have to set "nortc" anyway.
Then in latter of this script,

Code: [Select]

[ -z "$NORTC" ] || /etc/init.d/settime.sh &

so if "nortc" is set, it won't refer ntpserver to set the time from ntpserver....

[bmarkus]

so if "nortc" is set, it won't refer ntpserver to set the time from ntpserver....

For RPi nortc is the default in command line. If there is Ethernet connected and network is up, RPi system time is set up during boot from NTP server.

[y_satou70]

I see, so on RPi, it runs /etc/init.d/settime.sh -> /usr/bin/getTime.sh  by default.
then still not sure why we need to skip 2015 or later if we see on OS/kernel clock. shouldn't it be controlled by ntpserver boot option is set or not ...?

[Greg Erskine]

Hi y_satou70.

ntpserver bootcode:

Code: [Select]

Define alternative Network Time Protocol (ntp) server
<ntpserver=xxx.xxx.xxx.xxx> or <ntpserver=FQDN>
Default: pool.ntp.org
regards
Greg

[y_satou70]

yeah, I meant, if ntpserver=..... is set in boot option then it should always try to set time by NTP with specified ntpserver in bootoption, regardless what time currently OS/kernel has.

* If the system does not have RTC, then simply set "nortc". then it skip the logic to set OS/kernel clock from RTC/hardware clock (in /etc/init.d/tc-config)
* If system (regardless it's x86 or RPi) wants to set OS/kernel clock by NTP, then set ntpserver=... in boot option. And if this option is specified then it should sync the clock by NTP with using NTP server which is specified in ntpserver=... option., and regardless the time which RTC/hadware clock has.

that is my proposal and code diff for /etc/init.d/settime.sh

And,

> I believe that would cause issues on rpi with separate rtc. Those boot somewhat slow, and their users don't want the additional time taken by this if they already have a rtc set up. So conflicting requirements somewhat.

I'm afraid not following this part - "those boot somewhat slow" - slow for becoming RTC device available from OS ? or slow for syncing OS/kernel clock with ntpserver by /usr/bin/ntpd ?

[curaga]

Removing the date check as in your patch would result in systems that didn't need a NTP check now doing one. I agree that if the user gave a ntpserver= bootcode, then the NTP check should happen no matter what the time was. We'd need the proper logic for that - marking it as set in tc-config and then testing for this in the date check in setTime.sh.