Tiny Core Base > Raspberry Pi

getTime.sh fails at startup

(1/2) > >>

wis:
"getTime.sh" fails because it calls Busybox nptd with invalid arguments.

It uses the environment variable $NTPSERVER, which is set in "tc-config" to "96.114.29.7 204.2.134.164 192.3.170.116" from file /etc/sysconfig/ntpserver.

"getTime.sh" invokes ntpd thusly:

    /usr/sbin/ntpd -q -p $NTPSERVER

so the second and third server addresses are not prefixed with "-p", resulting in a return code of 1 and system time is not updated. At

If you run ntpd like this:

    /usr/sbin/ntpd -q -p 96.114.29.7 -p 204.2.134.164 -p 192.3.170.116

it has return code 0 and sets the time.

I suppose $NTPSERVER should be expanded in "getTime.sh" with each item pre-pended with "-p".

In a related matter, "settime.sh" calls "getTime.sh" and does not check the return code. It loops until /bin/date returns with a year > 2018. Given "getTime.sh" doesn't get the time due to the above failure, "settime.sh" will loop until its counters expire and then return, without the time being set and no indication of this.

It seems the logic of this could use improvement.

Rich:
Hi wis
Welcome to the forum.

getTime.sh  was originally written for a file that contained one entry, like this:

--- Code: ---tc@E310:~$ cat /etc/sysconfig/ntpserver
pool.ntp.org
tc@E310:~$
--- End code ---

If you change  getTime.sh  to this:

--- Code: ---#!/bin/busybox ash
# bmarkus - 26/02/2014

NTPSERVER=""

for S in $(cat /etc/sysconfig/ntpserver)
do
NTPSERVER="$NTPSERVER -p $S"
done

/usr/sbin/ntpd -q $NTPSERVER
--- End code ---

Then run a backup on  getTime.sh.
When you reboot, tc-config will restore your modified file
before it calls  settime.sh , it should then work as expected.

wis:
Worked fine. Thanks.

Rich:
Hi wis
You are welcome. Thank you for confirming your success.

CentralWare:
Good morning, @wis!

On our end, we had to stop using getTime/settime the way it was intended as there are other factors that creep in which should be considered.

First, on many occasions (RasPi-0/2, RasPi-1 through RasPi-4, Pi 5 was not tested but likely has this "issue") sometimes, especially on a WARM boot, it takes a little longer for the network hardware to come to life and since we've already zoomed past everything, we're already finished loading bootsync/bootlocal and not all of the hardware has settled yet. This is true for wired ethernet, onboard wireless and frequently USB ether and wifi dongles. This tiny lag can turn into a longer one if ntpd is sitting idle waiting for a second call to a server because the first one timed out due to hardware not being ready when it launched.

Secondly, there are also times where RasPi is intentionally accompanied by a Real-Time Clock circuit, which you'll want to take advantage of during boot to speed things along even more.

The logic we use is:
1. If RTC exists, load RTC results into DATE and run the following in the background, if no RTC, foreground
2. Wait for hardware to come up (see etc/init.d/tc-functions > search for wait4server as a good example)
3. Wait for eth0/wlan0/etc. to have an active inet addr in ifconfig
4. Ping the network gateway (or an online server, etc.) to verify we're "online" - if using DHCP, the gateway IP is already in sudo route | grep default by this point)
5. Call an NTP server of your choosing and update RTC and/or DATE (NTP sets RPC, RPC sets DATE)

We save the content in /opt/bootnet.sh and call it from bootsync.sh, but each person's preferences will differ where/how/when/etc.
Run backup and it becomes permanent.  (Our bootnet.sh also handles static IPs, Wake-on-Lan, network shares, etc. which is why I didn't just copy/paste ours here; sorry!)

Welcome to TinyCore and good luck!

Navigation

[0] Message Index

[#] Next page