I have a webcam which uploads images to my web host about every two minutes. If there was an Internet connection problem, it would be noted in the log file. Nothing for the time period immediately before and after Oct 28 14:05:09.
I also keep a log of changes in external IP address. This is usually caused by a dropped ADSL connection. Here are the entries for the time period around October 24 at 1400:
Wed Oct 28 12:58:39 ICT 2015 49.48.99.42
Wed Oct 28 13:58:45 ICT 2015 223.207.172.195
Wed Oct 28 16:38:57 ICT 2015 49.48.85.175
Wed Oct 28 17:18:59 ICT 2015 49.48.92.196
I think from looking at your logs the large time jumps you are seeing can only be caused by bad ntp servers whose time is wrong by many hours. āTime has been changedā is a systemd message that alerts you when the time has been changed by a large amount.
Even if ntpd just crashed by itself, the time would not suddenly be out by hours, it would still be correct but then very gradually drift, no more than a few seconds per day most likely.
Large jumps in time can only mean that it is syncing with bad servers. We really need to see the output of this command, taken at multiple times of the day, before and after the time is wrong:
ntpq -c peers
This command needs to be run when ntpd is running otherwise it wonāt give any useful output.
Also, can you please turn on debugging for ntp, by editing /etc/ntp.conf, remove the comment # from the statsdir line (second line below):
# Enable this if you want statistics to be logged.
statsdir /var/log/ntpstats/
Then restart the ntp service. This will enable logging in /var/log/ntpstats. After the problem occurs, please post the logs:
OK, I will do my best to do all. I did the ntpq -c peers for four machines on my LAN:
Pi Running OSMC:
osmc@OSMCBR:~$ ntpq -c peers
remote refid st t when poll reach delay offset jitter
==============================================================================
*203.146.215.116 202.47.249.20 2 u 217 256 377 64.139 7.268 37.997
Pi Running Raspbian:
remote refid st t when poll reach delay offset jitter
==============================================================================
+124.109.2.169 122.155.169.213 3 u 500 1024 257 55.963 -3.992 24.100
*103.22.182.121 202.47.249.20 2 u 162 1024 265 40.893 -20.743 32.951
Vero running OSMC:
remote refid st t when poll reach delay offset jitter
==============================================================================
*x2204.ipv9.xyz 202.47.249.21 2 u 125 1024 247 99.905 6.429 37.642
+203.158.247.150 131.214.52.161 3 u 2017 1024 376 99.748 19.287 17.911
Mac running El Capitan
remote refid st t when poll reach delay offset jitter
==============================================================================
*sgsin3-ntp-002. .GPSs. 1 u 36 64 377 71.706 0.904 52.565
It took almost ten seconds for the Pi running OSMC to respond to the query. All three other machines were almost instant. The time on this machine was correct when the query was done.
I have enabled debugging for ntp and have restarted the ntp service.
Iām afraid I donāt have much for you. After enabling ntp logging the Pi started crashing. Oddly, after enabling ntp logging I never again saw the time errors. Instead the Pi just crashes. I have no idea if the two are related.
Any idea why journalcrl jumps from October 28th to November 5th?
Oct 28 14:05:11 OSMCBR sudo[464]: pam_unix(sudo:session): session opened for user root by osmc(uid=0)
Nov 05 05:49:40 OSMCBR systemd[427]: Time has been changed
What do you mean by crash exactly, do you mean you canāt even log in with SSH after the crash, or is it just Kodi crashing ?
If you are getting a hard freeze then you almost certainly have some hardware instability that needs solving. You need to check the power adaptor, SD card, and it may be worth doing a fresh install as well.
Thereās not much point trying to troubleshoot a subtle issue like the time being wrong if the whole system is unstable - you should not be getting a system freeze just because you enabled ntp debugging, linux is not unstable in that wayā¦
I have no problem helping you get to the bottom of the time issue, but if the system is unstable then that instability could be the cause of the issue, leading to us running around in circles looking for a bug that doesnāt exist. At the very least it will hinder any troubleshooting.
Have you tried a different power adaptor ? I still see in your log that http-time is unable to connect during boot, while I initially thought that may be a network issue I now wonder (after seeing system instability) whether this is a power related issue, as the CPU is very busy during boot which puts it in Turbo mode, increases the power requirements, and can cause the Ethernet port to stop working temporarily.
Could you try running the following command via SSH after it has booted to see if it is able to set the date ?
sudo /usr/bin/http-time
You should see something like:
osmc@rpi2:~$ sudo /usr/bin/http-time
Updated time from Thu Nov 5 10:58:34 UTC 2015 to Thu Nov 5 10:58:34 UTC 2015 using HTTP query to www.google.com
If it fails try it a few times to see if it always fails. It would be interesting to see whether this fails or succeeds when run after booting up. If this does succeed when run manually, and coupled together with a general instability I would be suspicious of the power supply to the Pi.
Reminds me of my ISP. I was having horrible problems with my ADSL connection being unstable. They insisted it was my router and refused to do a service visit until I bought a new one. So, I bought a new one. The problems persisted. They came out and switched cable pairs and the ADSL instability disappeared.
So, I bought a new router for nothing.
I put the old ābadā one in my beach condo where it continues to perform flawlessly.
The power supply on my Pi was purchased from the official Raspberry Pi organization. I only bought it because someone here insisted that the one I was using must be bad.
Th ābadā power supply continues to perform well on a different Pi running my web cam under Raspbian.
However as far as Iām concerned your system is unstable - I can tell you as a fact from nearly 20 years using Linux that there is no way that just enabling debug logging for ntp is going to cause hard system freezes unless there is an underlying instability issue with the system, and almost certainly a hardware related issue.
Until you figure out what that issue is and fix it out you are going to continue to have problems with this system. Youāve already said that you have another system running OSMC that does not have any problems with setting the time, that alone should make it obvious that there is a problem with this system.
You are experiencing networking (potentially DNS) related issues, and odd ones at that. On your Pi 1, you had issues with wget connecting to Google but moments later were able to ping. State="ready" infers that while your link is established, your ability to connect to the Internet is yet to be determined (the connection manager canāt reach ipv4.online.osmc.io).
This is either an ISP issue or a problem with DNS. The quickest way to resolve this issue is to do as follows:
Looks like slow DNS servers to me. After a reboot (to clear the DNS cache) try:
time wget --server-response --timeout=20 --max-redirect 0 --spider www.google.com
To see how many seconds it takes to resolve - obviously more than 4 seconds if it was timing out after 4 seconds before.
What DNS servers are allocated in /etc/resolv.conf and are the same DNS servers you have allocated on your Mac ?
EG do you use DHCP for all machines or are some using a static configuration ?
Edit: I have a pretty good idea of what it probably is - please provide a copy of /etc/resolv.conf both from your Pi and from your Mac.
There is a known bug in OSMC at the moment that the order of dns servers in /etc/resolv.conf is reversed from what it should be so if you have a primary and secondary server allocated and the secondary sever doesnāt work or is slow OSMC is trying to use that faulty secondary server first while your other OSās like Mac OS will be using the correct primary server.
osmc@OSMCBR:/usr/bin$ cat /etc/resolv.conf
# Generated by Connection Manager
nameserver 110.164.252.222
nameserver 8.8.4.4
Bleach:~ mnewman$ cat /etc/resolv.conf
#
# Mac OS X Notice
#
# This file is not used by the host name and address resolution
# or the DNS query routing mechanisms used by most processes on
# this Mac OS X system.
#
# This file is automatically generated.
#
nameserver 8.8.8.8
nameserver 8.8.4.4
nameserver 208.67.222.222
nameserver 208.67.220.220
nameserver 192.168.0.1
All the machines on my LAN have static IP addresses (except for guests)
After reboot:
osmc@OSMCBR:~$ time wget --server-response --timeout=20 --max-redirect 0 --spider www.google.com
Spider mode enabled. Check if remote file exists.
--2015-11-06 05:46:26-- http://www.google.com/
Resolving www.google.com (www.google.com)... 110.164.6.232, 110.164.6.236, 110.164.6.231, ...
Connecting to www.google.com (www.google.com)|110.164.6.232|:80... connected.
HTTP request sent, awaiting response...
HTTP/1.1 302 Found
Location: http://www.google.co.th/?gws_rd=cr&ei=Qtw7VvTPOaixmwXmmY6wAQ
Cache-Control: private
Content-Type: text/html; charset=UTF-8
P3P: CP="This is not a P3P policy! See http://www.google.com/support/accounts/bin/answer.py?hl=en&answer=151657 for more info."
Date: Thu, 05 Nov 2015 22:46:26 GMT
Server: gws
Content-Length: 261
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
Set-Cookie: PREF=ID=1111111111111111:FF=0:TM=1446763586:LM=1446763586:V=1:S=0C2VYsDk5aeHQJEB; expires=Thu, 31-Dec-2015 16:02:17 GMT; path=/; domain=.google.com
Set-Cookie: NID=73=McO3VLwOzjFyLnSluE5zlYCg-39aiAwWElO2YFRGW5cBlY51zi8BKms5eh3KfkFHpbGFQo5kRQca2YV9fqIF-SVoIdXjdFKTtW9xPlXAlAPF7QuH22k90WDvzP2FS0T_kXM_qKGf829V4fLAbOUf-0TzTU3R8w; expires=Fri, 06-May-2016 22:46:26 GMT; path=/; domain=.google.com; HttpOnly
Location: http://www.google.co.th/?gws_rd=cr&ei=Qtw7VvTPOaixmwXmmY6wAQ [following]
0 redirections exceeded.
real 0m1.059s
user 0m0.040s
sys 0m0.040s
==
osmc@OSMCBR:~$ sudo http-time
Updated time from Thu Nov 5 22:49:04 UTC 2015 to Thu Nov 5 22:49:05 UTC 2015 using HTTP query to 139.162.18.76
Let me know if I failed to do anything requested. Itās very early in the morning hereā¦.