OK - called them, no one is able to confirm their setup. Will have to wait for Monday before they will call me back.
djeez.
I already poured me a glass of Scotch to celebrate.
Hold on that Scotch for now…
Wait with that. I’m coming over
I hope the ice ball will last 2 days… I still haven’t got that phone call.
How’s that ice ball going guys? It’s been a week and I still not getting out of this situation. My ISP keeps telling me that they don’t block NTP, but since I’ve recently installed a new Orbi router, I also noticed that when I tried to sync Orbi to NTP, it also failed, timeout.
I’ll get to another call with the ISP later today or tomorrow, but I found something interesting that I want to share with you both:
- I tried again to run systemctl stop ntpd and systemctl start ntpdate - failed, same error message like above posts
- Interestingly my date doesn’t seem to move out from Friday July 6th, 2018 - it stays there forever, maybe it is also to do with the daily reboot routine that reset it back to that date
- I then tried to change the date using the “date” command - which I also found that whenever the date is changed, Ropieee will force reboot itself.
[root@ropieee ~]# date +%Y%m%d -s “20181029”
20181029
Broadcast message from root@ropieee (Mon 2018-10-29 00:00:00 HKT):
The system is going down for reboot NOW!
[root@ropieee ~]# Connection to ropieee.local closed by remote host.
Connection to ropieee.local closed.
-
When i reconnect after that, the date and time are now correct. I mean I didn’t update the time, as you can see above, it actually showing the right date, but time was showing 00:00:00 but after the reboot, I got it right by itself.
-
When I then tried to use ntpdate, it is still showing timeout, and my Orbi still unable to connect to NTP
I think I should just stop and accept this, but if this somehow help you guys, the experts, to point out what i can try next, I’ll be willing to give it another go. I’ve a curious mind!
Thanks.
The date in question, 6th of july, is the build date of the image.
Since the Pi does not have a clock of it’s own, it is started with that time.
If you set the date/time manually it just writes the date to disk on a reboot.
You still need to resolve the NTP issue. Can you try running ntpdate with -u flag (unprivileged ports)? So
ntpdate -u pool.ntp.org
Thanks
yes - that works:
Last login: Mon Oct 29 19:59:38 2018 from fe80::1cc9:b13d:cbbb:9f96%eth0
[root@ropieee ~]# ntpdate -u pool.ntp.org
29 Oct 20:12:33 ntpdate[6027]: adjust time server 103.226.213.30 offset -0.000968 sec
[root@ropieee ~]#
what’s the different from the systemctl start ntpdate?
hmmm… wow.
So… can you please retry
systemctl start ntpdate
and do a:
systemctl status ntpdate
[root@ropieee ~]# systemctl start ntpdate
Job for ntpdate.service failed because the control process exited with error code.
See “systemctl status ntpdate.service” and “journalctl -xe” for details.
[root@ropieee ~]#
***** ntpdate.service - One-Shot Network Time Service
Loaded: loaded (/etc/systemd/system/ntpdate.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Mon 2018-10-29 20:30:28 HKT; 55s ago
Process: 7250 ExecStart=/usr/bin/ntpd -q -n -4 -g -u ntp:ntp (code=exited, status=1/FAILURE)
Main PID: 7250 (code=exited, status=1/FAILURE)
Oct 29 20:30:28 ropieee ntpd[7250]: Command line: /usr/bin/ntpd -q -n -4 -g -u ntp:ntp
Oct 29 20:30:28 ropieee ntpd[7250]: 29 Oct 20:30:28 ntpd[7250]: ntpd 4.2.8p11@1.3728-o Sun May 20 16:15:32 UTC 2018 (1): Starting
Oct 29 20:30:28 ropieee ntpd[7250]: 29 Oct 20:30:28 ntpd[7250]: Command line: /usr/bin/ntpd -q -n -4 -g -u ntp:ntp
Oct 29 20:30:28 ropieee ntpd[7250]: proto: precision = 0.781 usec (-20)
Oct 29 20:30:28 ropieee ntpd[7250]: 29 Oct 20:30:28 ntpd[7250]: proto: precision = 0.781 usec (-20)
Oct 29 20:30:28 ropieee ntpd[7250]: unable to bind to wildcard address 0.0.0.0 - another process may be running - EXITING
Oct 29 20:30:28 ropieee ntpd[7250]: 29 Oct 20:30:28 ntpd[7250]: unable to bind to wildcard address 0.0.0.0 - another process may be running - EXITING
Oct 29 20:30:28 ropieee systemd[1]: ntpdate.service: Main process exited, code=exited, status=1/FAILURE
Oct 29 20:30:28 ropieee systemd[1]: ntpdate.service: Failed with result ‘exit-code’.
Oct 29 20:30:28 ropieee systemd[1]: Failed to start One-Shot Network Time Service.
That’s what I got… i don’t understand it.
I do
ntp is running again. So do:
systemctl stop ntpd
systemctl start ntpdate
systemctl status ntpdate
Here’s what I got - this time i didn’t get any error message from “systemctl start ntpdate” - what has changed?? Did the earlier “ntpdate -u pool.ntp.org” somehow forced the system to recognize to use unprivileged port instead of 123?
[root@ropieee ~]# systemctl stop ntpd
[root@ropieee ~]# systemctl start ntpdate
[root@ropieee ~]# systemctl status ntpdate
- ntpdate.service - One-Shot Network Time Service
Loaded: loaded (/etc/systemd/system/ntpdate.service; enabled; vendor preset: disabled)
Active: inactive (dead) since Mon 2018-10-29 20:36:12 HKT; 7s ago
Process: 7633 ExecStart=/usr/bin/ntpd -q -n -4 -g -u ntp:ntp (code=exited, status=0/SUCCESS)
Main PID: 7633 (code=exited, status=0/SUCCESS)
Oct 29 20:36:03 ropieee ntpd[7633]: Listen normally on 1 lo 127.0.0.1:123
Oct 29 20:36:03 ropieee ntpd[7633]: Listen normally on 2 eth0 192.168.1.152:123
Oct 29 20:36:03 ropieee ntpd[7633]: 29 Oct 20:36:03 ntpd[7633]: Listen normally on 1 lo 127.0.0.1:123
Oct 29 20:36:03 ropieee ntpd[7633]: 29 Oct 20:36:03 ntpd[7633]: Listen normally on 2 eth0 192.168.1.152:123
Oct 29 20:36:03 ropieee ntpd[7633]: 29 Oct 20:36:03 ntpd[7633]: Listening on routing socket on fd #19 for interface updates
Oct 29 20:36:03 ropieee ntpd[7633]: Listening on routing socket on fd #19 for interface updates
Oct 29 20:36:12 ropieee ntpd[7633]: ntpd: time slew +0.003340 s
Oct 29 20:36:12 ropieee ntpd[7633]: 29 Oct 20:36:12 ntpd[7633]: ntpd: time slew +0.003340 s
Oct 29 20:36:12 ropieee ntpd[7633]: ntpd: time slew +0.003340s
Oct 29 20:36:12 ropieee systemd[1]: Started One-Shot Network Time Service.
[root@ropieee ~]# [
Hmmm… everything works as expected.
Nothing changed. So my best guess? Something in the infrastructure changed.
Maybe someone at your ISP flipped the switch anyhow
That’s the thing… I am sure they must have done something without telling me anything!
I’ll try to restart…
FYI - when I tried to sync my router to the NTP servers, it still failed… so… it must be something else, not the ISP…
I restarted, and everything back to square one.
The date is back to Friday, July 6th, 2018 and now if I tried to do “ntpdate -u pool.ntp.org” it will immediately restart (as you said, it writes the new date to the disk and reboot).
I can see that it captured the right date and time before reboot, but the thing is, after reboot, it goes back to Friday July 6th.
So I repeated the steps earlier:
- use date command: date +%Y%m%d -s “20120418”
- the system will auto reboot
- again, after reboot it is back to Friday July 6th
I’m going to stop here tonight… late for me, will come back tomorrow…
The date always goes back to the 6th of July. Again, the Pi does not have a RTC.
So there is nothing wrong with what happens with your system.
It’s unclear to me what you think is wrong at this point.
I have this exact problem since i did the update to 337
From SSH the command: ntpdate -u pool.ntp.org sets the correct time, but after reboot the date/time is wrong again. Help!