Clock is way off

OK - called them, no one is able to confirm their setup. Will have to wait for Monday before they will call me back. :frowning:

djeez.

I already poured me a glass of Scotch to celebrate.

Hold on that Scotch for now… :slight_smile:

1 Like

Think I might have one myself…might crack the Copper Dog over a nice 50mm ice ball

3 Likes

Wait with that. I’m coming over :wink:

1 Like

I hope the ice ball will last 2 days… :slight_smile: I still haven’t got that phone call. :slight_smile: :slight_smile:

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:

  1. I tried again to run systemctl stop ntpd and systemctl start ntpdate - failed, same error message like above posts
  2. 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
  3. 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.

  1. 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.

  2. 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. :slight_smile: 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 :wink:

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 :wink:

That’s the thing… I am sure they must have done something without telling me anything! :slight_smile:

I’ll try to restart… :wink:

FYI - when I tried to sync my router to the NTP servers, it still failed… so… it must be something else, not the ISP… :thinking::thinking::thinking:

I restarted, and everything back to square one. :frowning:

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:

  1. use date command: date +%Y%m%d -s “20120418”
  2. the system will auto reboot
  3. again, after reboot it is back to Friday July 6th

I’m going to stop here tonight… late for me, will come back tomorrow… :frowning:

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! :slight_smile: