[Solved] NTP server doesn't look like working fine

[Duud]

I installed SLI-only Debian 12, and installed NTP on it in this way:
https://timetoolsltd.com/ntp/how-to-ins ... -on-linux/

I added my Windows domain controller IP address in the ntp.conf file and commended out the Debian pools, because this server isn't supposed to have internet access. When I ran ntpq -p, I got:

remote refid st t when poll reach delay offset jitter
=======================================================================================
+xxx.xxx.xxx.xxx 61.239.100.17 2 u 7 64 377 1.1269 -14398695 0.6500

Note the '+' symbol and the offset.

I added 'tos maxdist 16' to no avail.

I created this Debian server to replace and old CentOS server that was working. It used Chrony though.

Both servers are on the same subnet, while the DS is on another.

What is missing?

[ruwolf]

I do not know, but −14398695 ≈ −4 × 3600 × 1000, so I bet for problem in UTC vs. local time in Microsoft Windows...

[Duud]

My time is actually +4. So according to your calculation, this is an 8-hour difference.

But regardless, how about the '+' symbol, doesn't it have to be '*' instead? How to make sure the server is working, or how to fix this problem?

[ruwolf]

On Debian machine, you can see local time in ISO format (in minutes) by command

Code: Select all

date -Im

(You can check it in UTC by:)

Code: Select all

date -uIm

On Microsoft Windows machine, you can see local time almost in ISO format (in minutes) in PowerShell:

Code: Select all

Get-Date -UFormat "%FT%R%Z"

(You can check it in UTC by:)

Code: Select all

Get-Date -asUTC -UFormat "%FT%R%Z"

You can set hardware clock as UTC in Microsoft Windows in registry:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation]
"RealTimeIsUniversal"=dword:00000001


+ indicates the host is included in the final synchronization selection set (peer selected for possible synchronization)
* indicates the current synchronization source (synchronized to this peer)
In my opinion, it cannot be synchronized with such huge offset.

[Duud]

I just use 'date', and it gives me a clear format that is very easy to see and understand. I prefer it over using '-Im'.

username@hostname:~$ ntpq -p
remote refid st t when poll reach delay offset jitter
================================================================================
+xxx.xxx.xxx.xxx 61.239.100.17 2 u 29 64 377 1.0248 -14398483 0.6920
username@hostname:~$ date
Sat Apr 6 09:52:25 AM +04 2024
username@hostname:~$ date -Im
2024-04-06T09:52+04:00
username@hostname:~$

But most importantly, the date and time of the NTP server are correct, and match those of the domain controller.

So, the question remains. How to make sure this NTP server is working, or how to fix this problem?

[ruwolf]

And what is the time zone an UTC on mentioned Windows domain controller?

[Duud]

I am not sure if I haven't been clear enough or something else.

The time zone on all servers and client computers starting from the PDC downwards is UTC + 4:00. They all match, zone-wise and time-wise.

[Aki]

Hello,

The time zone on all servers and client computers starting from the PDC downwards is UTC + 4:00. They all match, zone-wise and time-wise.

Perhaps another time synchronization service (different from ntpd) is running on Debian ?

What are the full contents of the ntpd configuration file (/etc/ntp.conf) ?

What is the output of the following commands (root password is required), replacing "your-win-time-server" with the IP address of your Windows PDC:

Code: Select all

script log.txt
timedatectl status
timedatectl show-timesync
su -l -c "systemctl status systemd-timesyncd.service"
systemctl status systemd-timesyncd.service
su -l -c "apt install ntpdate"
su -l -c "ntpdate -v -q your-win-time-server"
su -l -c "ntpdate -v -q 61.239.100.17"
exit

[Duud]

@Aki this is a fresh server that I created and only configured NTP on it.
The path happened to be /etc/ntpsec/ntp.conf.

root@Hostname:/# date
Wed Apr 10 08:38:09 AM +04 2024
root@Hostname:/# ntpq -p
remote refid st t when poll reach delay offset jitter
===================================================================================
+xxx.xxx.xxx.xxx 61.239.100.17 2 u 62 64 377 1.0511 -11131.9 1.5088

Pease find the enclosed files.

[Aki]

Hello,

You may install the package ntpstat package to check if ntpd is running and configured:

Code: Select all

apt install ntpstat
ntpstat

[Duud]

Today, I was given internet connection on my NTP server, and installed ntpstat. Before I lose the internet, I edited the configuration file enabling the Debian default pools 0, 1 and 2, and commenting out the domain controller and 'tos maxdist 16'. The result was as in the first screenshot.

Then, I commented out the default pools and enabled the DC and tos. The result was as in the second screenshot.

I also noticed that the offset is getting less by the time. Like the last time I checked it before today, it was -10xxx, and today before I do ntpstat, it was -9xxx.

https://postimg.cc/zVFJWcYk
https://i.postimg.cc/bJxwjrB5/2.png

[ruwolf]

Offset 14398695 ms in the first post vs. 15 ms in the last is million times less, it is huge improvement.

[Duud]

The 15 came when I was testing with Debian pools. That was when I still had internet on that server. After that, I reverted the setting that I want. I explained this in the post to which you replied.

And with this setting, the offset dropped even further to -0.85, which I guess should be OK. But how about the asterisk (*), should we see it instead of the plus (+)?

In other words, what makes us know that the NTP server is doing what it's supposed to do? And why did it take all these days to drop from -14000000 to -0.85? Because I didn't correct the configuration. I just installed the 'ntpstat' package, like @Aki suggested, to be able to see the status.

[Augie77]

Following with interest, I recently used the pool for time service. I believe I read your time server is not to be on the open net, if that is the case, what are you using to derive the timing from? Perhaps the issue is there, if it is a clock local to your premise? Do you mistakenly have chrony installed?

dpkg -s chrony

dpkg -s chronyd

dpkg -l chrony If the first two characters are ii, then the package is installed.

[ruwolf]

And why did it take all these days to drop from -14000000 to -0.85? Because I didn't correct the configuration. I just installed the 'ntpstat' package, like @Aki suggested, to be able to see the status.

It is due algorithm, which prevents large jumps in time measurement. Other processes dependent on time measuring could collapse by such big jumps.
man ntpd: How NTP Operates

[Augie77]

By no means am I an expert on timing. I took note of that documentation when I sat up my timing. The way I see this is that for the algo to be an issue, his system would need to have a error/panic of some time, likely related to system RTC/hardware; along with no drift file being created. As his system is taking days to come into a reasonable time frame, I would think there is no drift file being created either.

The data the OP last published, showed a ' + ' before the timing source and that means it is recognised as available but not actively in use. This is validated when his record shows there is no syncing. If his one time source is not being seen as preferred then there is an issue with his server configuration, possibly a time zone issue (big guess on my part). He can try something like

server ip minpoll maxpoll iburst prefer but I doubt that will help.

He should check to see if there is a path for the drift file and if the file exists. Maybe look for errors with journalctl -r -t err

See what journalctl -r -t ntpd reports.

What is the time source? That is a big mystery, maybe time source is NASA NTP laser on moon and there is a bit of drift?

[Duud]

@Augie77 dpkg package isn't installed. And if I want to install it, I need to have approval again for internet. But I'm sure chrony isn't installed, because I was the one who installed Debian and then NTP in the way I mentioned in the OP.

@ruwolf what I understand is that it should take minutes, not hours or days. And I don't understand why the offset is high (or low) when the the time is actually not wrong to start with.

After all, it say 'unsynchronised' like in the screenshot in my last reply.

In addition, today the offset is not so good as at the last time. See this:
https://i.postimg.cc/tCwD4DXC/Untitled.png

@Augie77 again, the drift file exists. And the source for this Debian NTP server is the Windows PDC.
https://i.postimg.cc/ZK8sN7rV/Untitled2.png

====================================================
I was drafting this reply to you guys when someone I know visited. I don't think he is expert in NTP, but he is in Linux in general. He tried so many things and commands most of which are not installed on my newly installed Debian. I couldn't catch everything he did. And now the active lines in ntp.conf are:

driftfile /var/lib/ntpsec/ntp.drift
leapfile /usr/share/zoneinfo/leap-seconds.list
server xxx.xxx.xxx.xxx prefer (This is the IP address of the PDC)
restrict 127.0.0.1
restrict ::1
tos maxdist 16

And the result now looks like this:
https://i.postimg.cc/fLkmzLv6/Untitled3.png

The report of journalctl -r -t ntpd started from 16/04/2024 before he came. And now it starts from 19/04/2024.

He also doesn't know exactly what made it work.

[Augie77]

Glad to read the issue has been fixed. If you want to see what commands he used, open Terminal and then use the 'up arrow' and 'down arrow' to see what was entered. You will have to be the same sudo/su user to see the entries. Don't hit enter/cr at each entry or you may undo what he fixed. This will give you a list of actions he took and you can copy/paste/save those for future use.

[ruwolf]

@ruwolf what I understand is that it should take minutes, not hours or days. And I don't understand why the offset is high (or low) when the the time is actually not wrong to start with.

After all, it say 'unsynchronised' like in the screenshot in my last reply.

In addition, today the offset is not so good as at the last time. See this:
https://i.postimg.cc/tCwD4DXC/Untitled.png

nptd can be run with -g option, which enables big jumps in correction steps. It is recommended option, if ntpd is running for the first time.
As mentioned @Augie77, nptd behave differently, when its drift-file was not created, yet.
By manual, in normal condition, when offset is over 1000s, it exits with panic.
But your offset was 4 h (cca. 14_400 s), so I do not know, what your ntpd was doing.

I do not know cause, why your initial offset was so huge and why it increased to 660 ms again.
But is/was your reference time server (you probably names it here Windows PDC) running correctly?
Or which time was stored in RTC/TOY in time (or minute before) of first run of your ntpd on Debian?

[Aki]

Hello @Duud,

It looks like you sorted it out. :)

Please, mark the discussion as "solved" manually adding the text tag "[Solved]" at the beginning of the subject of the first message; i.e. :

[Solved] NTP server doesn't look like working fine

EDIT Wed 8 May 07:42:49 CEST 2024: the discussion is marked as solved.