NTP Not Updating Automatically

[rhester72]

Still doesn't explain how so many of us *did* update the Linux version (which is full, by the way, not partial, so it wouldn't matter if you started with Mr. Fusion or not) and our clock still works as expected.

[Bas]

You get an IP and DNS resolver quickly enough for ntpdate to not bomb out.

[jlancaster86]

Ok. I think I have a better idea what's going on. As Bas has said, it seems to be just a timeout issue.

At startup, the settings in /etc/ntp.conf are used:

Code: Select all

server 0.pool.ntp.org iburst
server 1.pool.ntp.org iburst
server 2.pool.ntp.org iburst
server 3.pool.ntp.org iburst

# Allow only time queries, at a limited rate, sending KoD when in excess.
# Allow all local queries (IPv4, IPv6)
restrict default nomodify nopeer noquery limited kod
restrict 127.0.0.1
restrict [::1]

If I replace those four servers with my MikroTik router's IP address, it works just fine:

Code: Select all

server 192.168.54.254 iburst

# Allow only time queries, at a limited rate, sending KoD when in excess.
# Allow all local queries (IPv4, IPv6)
restrict default nomodify nopeer noquery limited kod
restrict 127.0.0.1
restrict [::1]

I tried using the Australian ntp.org servers, but they timeout too at this stage. Maybe there are some tweaks that can be done to this configuration file to increase the timeout and/or retry limits.

[jlancaster86]

I've tried messing around ntp.conf, but the only thing that works for me is using a local NTP server. I'll have to leave this to somebody who's better acquainted with Linux.

For now, I've tweaked my ntp.sh script to have it update the time a bit faster at startup. Now, instead of waiting 10 seconds befor trying to update, it will try immediately and retry up to 20 times with a 1-second pause between each attempt:

Code: Select all

#!/bin/bash

NTP_SERVER="0.pool.ntp.org"
i=0

while [ $i -lt 20 ]
do
	if ! ntpdate -bsu $NTP_SERVER
	then
		if $i == 19
		then
			echo echo "Unable to sync after 20 attempts."
		fi
		sleep 1s
		((i++))
	else
		echo "Date and time is:"
		echo "$(date)"
		i=20
	fi
done

[Bas]

Scripts like these imitate the behavior of a proper NTP client. The problem with those is that they normally slowly skew the clock in the right direction if it's off. That works well for small deviations but not when a system boots up thinking Nixon is still president. That's what ntpdate is for: big leaps at system startup, then the regular client takes over.

At this point the MiSTer boot process doesn't wait for proper network connectivity to perform this action. It should do that to fix the behavior that people expect.

A much more resilient way would be to run an NTP daemon like Chrony in the background. It's tiny and won't affect the rest of the system in a noticeable way. Chrony can be told to do big leaps whenever needed, so it won't have to wait for connectivity.

Sleeping some amount of time before firing up ntpdate is not a real solution either. Sure it works sometimes because you're usually more likely to have connectivity later, but nothing actually guaratees that at all so the failure mode is still there.

[mightor]

If I replace those four servers with my MikroTik router's IP address, it works just fine:

I also replaced the servers with my router's IP address, and it also works for me. Thanks for the idea.

[ioev]

Thank you for this! I'm having the same issue where ntp doesn't sync unless I manually run the rtc.sh script.

I checked my /var/log/messages file and it seems like there are a bunch of stack traces from my wireless adapter, so I'm assuming it just takes longer to connect now because of that.

[Lancelot]

Do we have a solucion to this yet? I have this exact problem, the date and date does not show up at startup and my MiSTer internet is fine. It worked before, the updates maybe messed up the things here. A brand new up to date installation does not fix this.

[theypsilon]

As a mitigation, the updater launchers now try to ntpdate if they see that date command is off. If you use downloader, reinstall the launcher to get this new version.

But this is no definitive solution and won't fix other clock usage problems in cores if you don't run any updater after booting or you don't have an internet connection. A better solution would be installing RTC add-on board, as it keeps the clock without depending on the network.

[thisisamigaspeaking]

Many routers permit you to set up the IP addresses of NTP servers to pass on to clients. That way the MiSTer could be passed a good set that works for you without disappearing again after every Linux update to the base system.

My router even has an NTPd, not sure how many do.

So the problem may have been introduced in the latest Linux versions. Keeping old Linux version is not an option as modern cores needs up to date Linux version. So while waiting for a fix, there are only two ways to get date/time at each boot: by manually running rtc.sh or by using your automated method to run a ntp.sh script at boot time.

Yeah, I just tried rolling back to menu_20210315.rbf, and the clock isn't updating. Looks like it's something in the Linux installation.

How many people are currently having this issue?

[Bas]

I guess I wasn't very clear in my original comment. Your router's DHCP service can set an NTP server as a DHCP option, which it will then pass down to the connecting clients. If it does that, a client has a hint as to which NTP server to sync from. If your router has its own NTP service on board, it's quite likely that it passes this option through its DHCP service as well. To close the gap, the client must actually make use of the information it gets handed from DHCP. If it doesn't do that, it's still useless.. but you could manually configure ntp to sync to the router's private IP address (the default gateway IP).

[Malor]

The Mister is using ntpd, which AFAIK pays no attention to DHCP whatever. It uses /etc/ntp.conf for configuration. In there are four lines for using pool.ntp.org servers.

If time isn't syncing, dropping to a command line, typing "ntpq", and typing "peers" will tell you a lot about the state of the daemon. If you need help interpreting, you can post that output here

Note that because it's going to pool.ntp.org by name, DNS needs to be working.

[Lancelot]

Tried to mess with the NTP settings on my router (Asus RT-AX88U) as a last resort but no dice. Maybe Sorgelig will take a look into this.

[Malor]

The settings on your router probably aren't what you need, and won't likely change anything.

The config file is on the Mister, /etc/ntp.conf.

[Lancelot]

The settings on your router probably aren't what you need, and won't likely change anything.

The config file is on the Mister, /etc/ntp.conf.

Thanks.

[rhester72]

One other completely random idea - you don't happen to have two MiSTers on the network at the same time, do you? By default, they all share one MAC address, which can be extremely disruptive to communications as a whole.

[Lancelot]

One other completely random idea - you don't happen to have two MiSTers on the network at the same time, do you? By default, they all share one MAC address, which can be extremely disruptive to communications as a whole.

Nop, just one. A friend has the same issue and others on this forum also, surely this is not an isolated case.

[Malor]

What does your /etc/ntp.conf look like?

I'm also running a local NTP server, but I was doing that originally, so if there's a problem syncing to outside servers, I wouldn't have seen it.

edit with a random thought: if your Mister can talk to your local network but can't get outside, make sure it's getting a default route from the DHCP server. Without a default route, a machine can't leave the local network. You can check with route -n:

Code: Select all

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         A.B.C.1		0.0.0.0         UG    0      0        0 eth0
A.B.C.0		0.0.0.0         255.255.255.0   U     0      0        0 eth0

That's saying that for any global address, forward to the address A.B.C.1. (usually routers are on .1, although they don't have to be.) I believe UG means Up, Gateway. (the default route.)

Then, for every IP address from A.B.C.0 to A.B.C.255, they're connected to the Ethernet port named eth0. Any machine with one of those IPs is on the same wire, and can be spoken to directly.

If you don't have the first line, then the machine can only talk to other machines on the same wire. If you don't have the second line, the machine can't talk to anything.

If you have three or more lines, you probably have a WiFi card connected and active at the same time as Ethernet. This is almost always a bad idea, unless you understand networking well enough to make it work properly.

Also make sure your /etc/resolv.conf says something sane. It should look at least like this:

Code: Select all

domain example.com
nameserver 8.8.8.8

The domain should be whatever you use locally. Nameserver can be any number with a valid DNS resolver. 8.8.8.8 is Google. 9.9.9.9 is Plan 9. I think they also run 1.1.1.1 as a nameserver. Any of those numbers should work unless your ISP is blocking them. Some do, because they want to snoop on your DNS queries.

The number could also be your router, at A.B.C.1. This is typically fine, as long as the router is working. Using all 8s or all 9s may be more reliable.

[Lakeside]

I'm going to have to spend some time on this as well. The last Linux update borked my MiSTer and now I can't run any of the scripts due to no NTP.

[jca]

Use Putty to ssh into your MISTer, go to the Scripts directory, run the rtc.sh script, even if you do not have a RTC, it will update your Linux Date and Time. You can also run update_all.sh after that.