getTime.sh fails at startup

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

tc@E310:~$ cat /etc/sysconfig/ntpserver
pool.ntp.org
tc@E310:~$
If you change  getTime.sh  to this:

Code: [Select]

#!/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
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!

[Rich]

Hi CentralWare

... 3. Wait for eth0/wlan0/etc. to have an active inet addr in ifconfig ...

That's what  settime.sh  does:

Code: [Select]

CNT=0
until ifconfig | grep -q Bcast
do
    [ $((CNT++)) -gt 60 ] && break || sleep 1
done

[CentralWare]

@Rich: We've had odd-ball instances where we have had to use iwconfig (for wireless, instead of ifconfig - but I THINK ethernet tools and drivers over the past number of years has all but eliminated that need - I haven't bothered checking/testing to know for certain) and/or cases (on WinNT networks) where a broadcast address becomes available before an actual assigned address, so our IP triggers are based on an IP (ie: 0.0.0.0, 127.x.x.x and 169.254.x.x are then ignored completely, 0 and 127 for obvious reasons unless 127's being used as a cross-over network and 169 for machines which are usually cabled directly together to Win based machines which don't offer a gateway or forwarding service) so this is just our way of covering all the bases WE know of historically, especially when using multiple NICs, unless DHCP Client is launched manually per device and nodhcp is used (Core) to help prevent WinNT temporary assignments or even mis-assignments on multi-homed networks.  (To each their own? Agree to disagree? Artistic Nerd License? Ridiculous metaphor about the number of way to skin a cat?  Was that really a thing?)

LOL - and sixty seconds for a network timeout is an eternity!   Except on dial-up and some old forms of single channel DSL!  Or...  "Hang on, maw!  I'm adjusting the satellite dish!"

[Rich]

Hi CentralWare

... LOL - and sixty seconds for a network timeout is an eternity!   Except on dial-up and some old forms of single channel DSL!  Or...  "Hang on, maw!  I'm adjusting the satellite dish!"

If you look at  settime.sh  in isolation, that might be true.

Examined in context, 60 seconds might not be such a bad choice.
Looking in  tc-config  we find this:

Code: [Select]

        [ -z "$DHCP_RAN" ] && /etc/init.d/dhcp.sh &
        [ -z "$NORTC" ] || /etc/init.d/settime.sh &Both  dhcp  and  settime  are launched into the background at the
same time. So right off the bat we are waiting for  dhcp  to finish.

dhcp  starts with this:

Code: [Select]

/sbin/udevadm settle --timeout=5So it could wait for up to 5 seconds for  udev.

Then, for each interface it finds, it executes this:

Code: [Select]

    /sbin/udhcpc -b -i $DEVICE -x hostname:$(/bin/hostname) -p /var/run/udhcpc.$DEVICE.pid >/dev/null 2>&1 &This command has been backgrounded. That may speed things up
since DHCP requests for multiple device will be sent out back to back.

Not being familiar with  udhcpc , I ask for some help. The following
options stood out to me, since they were not specified in the
original command:

Code: [Select]

tc@E310:~$ udhcpc --help
BusyBox v1.29.3 (2018-12-19 15:29:37 UTC) multi-call binary.

 ----- Snip -----
        -t N            Send up to N discover packets (default 3)
        -T SEC          Pause between packets (default 3)
        -A SEC          Wait if lease is not obtained (default 20)
 ----- Snip -----
If I am reading that correctly, in the worst case this would happen:

Code: [Select]

Time      Action
 00 Send  DHCP  request
 20 Wait 20 Secs for response
 23 Pause for 3 Seconds
 23 Send  DHCP  request
 43 Wait 20 Secs for response
 46 Pause for 3 Seconds
 46 Send  DHCP  request
 66 Wait 20 Secs for responseAnd if  udev  takes the full 5 Secs that's 71 Secs.

To me, this looks like hoping for the best (usual outcome), and
trying to plan for the worst (corner cases).

Since the timeout terminates once the interface is detected, faster
systems won't be impacted by a 60 Sec timeout.

[Paul_123]

The udhcpc that is built into busybox seems to struggle with some dhcp servers.  Most users get an address after the first or second dhcp request, but I have users that report much longer, specifically on newer routers and primarily on the wifi side.

Run ntpd in daemon mode if you really want to be sure time stays set properly.

[CentralWare]

Code: [Select]

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

This is just personal preference/taste, but IIWM my mind sees this as more efficient if it were dhcp.sh && settime.sh (in series) as the hardware we're physically running on isn't determined and tc-config is virtually identical with all platforms, but all of the platforms are "not created equal" so to speak. This is why we (on my end) have a dedicated networking script; to separate hardware based on platforms and to try and compensate for quirks that come with each.  Again, this is mere preference.

$NORTC only works if your RTC chip and its crystal are perfectly tuned...  the radio in my truck is almost +1min ahead every month, the clock above my fridge behind me is a good deal more than 1min behind per month - but it's a cheap clock!   RTC circuits are only as good as the crystal that makes them "tick."  That said, even RTC has to be updated from time to time.  The clock above this monitor...  -3 minutes since 01-01-24...  it's actually the closest non-netwoked clock here and it's only here because it's adhered to the bookshelf!!  HOWEVER, RTC works great for giving the system hardware clock a head start before we've had a chance to sync with an atomic clock somewhere.

The udhcpc that is built into busybox seems to struggle with some dhcp servers.  Most users get an address after the first or second dhcp request, but I have users that report much longer, specifically on newer routers and primarily on the wifi side.

I have found that dnsmasq (and in turn, WRT and similar projects) tends to be on the list of DHCP servers which busybox's udhcpc hiccups on.  Looking at logs, I cannot "see" what the issue is, but I get responses from dnsmasq 3, 4 or even 5 times and udhcpc doesn't seem to even "see" them, let alone accept the content, until numerous attempts have blown through then randomly...  "OH! Hello! Thanks for getting back to me!"  That said, I couldn't tell if it were udev not completely settled for ipv4 devices, BB's DHCP client, DNSmasq itself or something entirely out of the Twilight Zone...  finally I just said "screw it, we'll work around it."  If memory serves, I may have even posted things on the forum here back when RasPi-2 was young on this specific topic.