If this ^^ is indeed in you rc.local
(http://192.168.1.1/cgi-bin/luci/admin/system/startup) local startup tab.
No, you are done. Your log show the efforts and success. Done.
1 Like
In summary: your issues was two fold. The loss of the Gui caused by luci-app-ntpc, and the log error messages cause by the install of ntp-utils - 4.2.8p15-4. The error message below indicates that two ntp pid, or programs can not work together.
Once the offending packages were removed you are left with the default package ntpd - 4.2.8p15-4.
The rc.local file was then populated via LuCi or file system with the suggestion for using static ips to sync time over the wan interface upon boot of your system.
If you still have ntpdate installed, this is exactly what catches time correction first on my system; as depicted in the screenshot on the two thread you have viewed.
To be sure, do not confuse one with the other. Nothing is needed for ntpdate to function. Your modified rc.local is using ntpd
ntpd - 4.2.8p15-4
ntpdate - 4.2.8p15-4
If you still have ntpdate installed look at your system log and follow the time stamp changes to the first drastic switch. You'll see ntpdate did the adjustment first and several lines down. ntpd is called into play to do it again (request time and sync). That is two separate process that will not conflict with one another.
So, if the above is understood to be correct, you can proceed to reinstall the WireGuard interface and proceed with more confidence.
Lastly, if this is truly the resolution to both your threads, please consider marking the issues as solved found in this topic [Solved]. See How to mark a topic as [Solved] for a short how-to.
Thank you for the challenge, and don't forget to write. 
1 Like
only that error
Mon Jan 30 19:02:51 2023 daemon.info ntpd[11641]: Listening on routing socket on fd #63 for interface updates
Mon Jan 30 19:02:51 2023 daemon.info ntpd[11641]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized
Mon Jan 30 19:02:51 2023 daemon.info ntpd[11641]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized
Mon Jan 30 19:03:01 2023 user.notice ntpd: Stratum change, stratum= interval= offset=
I only kept ntpdate, but I added ntpd - 4.2.8p15-4 5 minutes ago
Reboot and then from shell, run command
logread | grep ntp
I stand corrected as the default Initscript is sysntpd which is the process the user rc.local script.
The package ntpd - 4.2.8p15-4 (I assumed incorrectly) is not on my system. Only ntpdate was added.
Regarding the error in you log, if only ntpdate is installed along side the default sysntpd and you are still seeing kernal reports, I'd honestly have to bow to SNAPSHOT.
Just rebooted myself to gather log.
/etc/config$ logread | grep ntp
Mon Jan 30 14:59:07 2023 kern.info kernel: [ 0.095164] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
Mon Jan 30 14:59:19 2023 daemon.err ntpdate[1930]: name server cannot be used: Try again (-3)
Mon Jan 30 14:59:24 2023 daemon.err ntpdate[2485]: name server cannot be used: Try again (-3)
Mon Jan 30 19:29:03 2023 daemon.notice ntpdate[2784]: step time server 96.248.124.200 offset +16172.636037 sec
Mon Jan 30 19:29:05 2023 daemon.notice procd: /etc/rc.d/S95done: ntpd: sending query to 203.114.74.17
Mon Jan 30 19:29:05 2023 daemon.notice procd: /etc/rc.d/S95done: ntpd: sending query to 162.159.200.123
Mon Jan 30 19:29:05 2023 daemon.notice procd: /etc/rc.d/S95done: ntpd: reply from 162.159.200.123: offset:+0.011324 delay:0.049981 status:0x24 strat:3 refid:0x04083c0a rootdelay:0.003891 reach:0x01
Mon Jan 30 19:29:05 2023 daemon.notice procd: /etc/rc.d/S95done: ntpd: reply from 203.114.74.17: offset:+0.000658 delay:0.278266 status:0x24 strat:2 refid:0x02b9ffdf rootdelay:0.051789 reach:0x01
Mon Jan 30 19:29:06 2023 daemon.notice procd: /etc/rc.d/S95done: ntpd: sending query to 203.114.74.17
Mon Jan 30 19:29:06 2023 daemon.notice procd: /etc/rc.d/S95done: ntpd: sending query to 162.159.200.123
Mon Jan 30 19:29:06 2023 daemon.notice procd: /etc/rc.d/S95done: ntpd: reply from 162.159.200.123: offset:+0.000992 delay:0.027783 status:0x24 strat:3 refid:0x06085e0a rootdelay:0.003281 reach:0x03
sorry for the delay, just before I reboot, Ive installed ntpd -4.2 and after rebbot, I have more errors so IM gonna remove it, but my sysntpdis disable on my side
Hopefully the removal of the package followed by a reboot will clear up sysntpd
Let see the log when your ready.
root@OpenWrt:~# logread | grep ntp
Mon Jan 30 19:48:43 2023 daemon.notice ntpdate[2475]: step time server 158.69.20.38 offset +597.761946 sec
Mon Jan 30 19:48:51 2023 daemon.notice procd: /etc/rc.d/S95done: ntpd: sending query to 162.159.200.1
Mon Jan 30 19:48:51 2023 daemon.notice procd: /etc/rc.d/S95done: ntpd: sending query to 149.56.37.32
Mon Jan 30 19:48:51 2023 daemon.notice procd: /etc/rc.d/S95done: ntpd: reply from 162.159.200.1: offset:+0.015731 delay:0.017884 status:0x24 strat:3 refid:0x7a08460a rootdelay:0.025788 reach:0x01
Mon Jan 30 19:48:51 2023 daemon.notice procd: /etc/rc.d/S95done: ntpd: reply from 149.56.37.32: offset:+0.027089 delay:0.023427 status:0x24 strat:2 refid:0xfe0aa8c0 rootdelay:0.070924 reach:0x01
Mon Jan 30 19:48:52 2023 daemon.notice procd: /etc/rc.d/S95done: ntpd: sending query to 162.159.200.1
Mon Jan 30 19:48:52 2023 daemon.notice procd: /etc/rc.d/S95done: ntpd: sending query to 149.56.37.32
Mon Jan 30 19:48:52 2023 daemon.notice procd: /etc/rc.d/S95done: ntpd: reply from 162.159.200.1: offset:+0.015910 delay:0.018847 status:0x24 strat:3 refid:0x7a08460a rootdelay:0.025849 reach:0x03
and should I enable the ntp server in system setting ntp time servers? I ask again sorry, just to be sure
That looks better!
you know I wasn't sure if this is needed.. but I checked my system and it is checked.. and I'm still running..
1 Like
So next step it to allow your WireGuard session some time doing .. whatever and post back in primary thread with update to issues or hopefully a nearly perfect system.
1 Like
You are both partially right.
- Peacefuleight has a build from the stable release branch . It is "stable".
- It is a "snapshot" , because it is not made from the exact release commit like 22.03.3. But it is a stable snapshot..., (Not from the unstable development master branch.)
- Installing 22.03.3 would mean to downgrade a few commits, as r20048-83a13b74f5 is 22.03.3 plus 20 later fix commits in 22.03. commit log in https://git.openwrt.org/?p=openwrt/openwrt.git;a=shortlog;h=83a13b74f5273ea1f541f71291d8362f226f4151
If 22.03.4 would be released today, it would be made from that exact commit in the stable 22.03 branch, as it is the current branch head...
6 Likes
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.