NTP update not working well

In my case, (v149), NTP has never worked as a proper NTP client, only as a SNTP client which updates hourly. Is Ipfire meant to do full NTP?

NTP depends on what your configuration asks to IpFire…

Interesting …

I should have added that if I update the time manually (while still
configured to update automatically) it always seems to update OK.


you may want to add your NTP configuration (menu Services > Time Server) and your NTP messages (menu Logs > System Logs >> Section NTP) to this thread to help debug.

All done as above but Ipfire is still not a true NTP client. (it is a Simple NTP client - SNTP)
Once an hour (the shortest interval allowed) my firewall does a hard time synch to the chosen upstream server and then proceeds to drift off frequency for an hour until the next update.

A true NTP client will want to see multiple upstream servers and then will start off synching to them at 64 second intervals and as the internal clock adjusts itself, will slow to about every 17 minutes.

This might help:

It adds a few lines to ntp.conf to make it act as you expected.

(Attachment log.dat is missing)

log.zip (1.24 KB)

Did this help?

Sadly - No

Ha! You’re going to need to give better hints on what is happening on your side. This is hard to fix otherwise…


ls -al /etc/ntp

and post the results.

1 Like

Hmm. I had similar problem after installation. I added manually some time servers into /etc/ntp.conf, and restarted ntpd. Now ntpq -p -n gives reasonable output. Maybe this could be documented on the Services → NTP Configuration page?

Hi Juha - Thank you for your post. Please take a moment to update and improve the NTP IPFire Wiki page. It is open to you (and everyone else) to improve and make better. You would login using the same ID and password as this Community.

If you have issues or questions, feel free to post a question. I’d be happy to help!

Thanks again!

1 Like

Well… What I would really want, is that the Services → Time Server cgi-script would install those Primary and Secondary NTP servers into /etc/ntp.conf. This is also what I think users expect. If this were done, there would be no need for manual editing. And we could get rid of the Synchronization dialog, because synchronization is just what real NTP is for :slight_smile: .

For the purpose of verification, it would be useful to let ntpd produce statistics. It takes a few more lines in /etc/ntp.conf. Here is a nice picture of how it works after I made these changes i my system:


1 Like

You need to alter /etc/ntp.conf and turn off the 1 hour sync.
Mine looks like

[root@wr-fw ~]# cat /etc/ntp.conf
disable monitor
restrict default nomodify
pool 0.au.pool.ntp.org
pool 1.au.pool.ntp.org
pool 2.au.pool.ntp.org
pool 3.au.pool.ntp.org
fudge stratum 10

More stuff here I just posted:

I think I am correct but if someone knows better I am all ears.
Works perfectly.

You may need to restart all hosts behind the firewall to pick up setting as they will all be syncing with their local clock. As far as I can see NTP is not working on IPFire and never has. THink I had to make the same changes to my IPCop install as well!

I see that ipfire.pool.ntp.org is not working at the moment.

How is this meant to be maintained?

Mine are set to the default, they are,

I just manually ran it, it did update.

Yes, it works if you add those lines as -
server 0.ipfire.pool.ntp.org
server 1.ipfire.pool.ntp.org

but the pool command does not.
For instance -
pool nz.pool.ntp.org returns a total of 8 valid servers but
pool ipfire.pool.ntp.org returns none.

I just had to chnage my ntp conf again to get ntp working correctly…


[root@wr-fw ~]# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
*LOCAL(0)        .LOCL.          10 l   60   64  377    0.000   +0.000   0.000

[root@wr-fw ~]# cat /etc/ntp.conf-01
disable monitor
restrict default nomodify noquery
server prefer
fudge stratum 10
driftfile /etc/ntp/drift


[root@wr-fw ~]# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
 0.au.pool.ntp.o .POOL.          16 p    -   64    0    0.000   +0.000   0.000
 1.au.pool.ntp.o .POOL.          16 p    -   64    0    0.000   +0.000   0.000
 2.au.pool.ntp.o .POOL.          16 p    -   64    0    0.000   +0.000   0.000
 3.au.pool.ntp.o .POOL.          16 p    -   64    0    0.000   +0.000   0.000
 bitburger.simon .GPS.            1 u    7   64    7   66.088  +17.137  52.880
 any.time.nl     2 u    7   64    7   51.028  +21.269  51.868 (   2 u   10   64    7   52.973  +21.902  51.417
 ntp2.ds.network    4 u   11   64    7    7.019  +21.396  51.591
 time.cloudflare        3 u   12   64    7    6.542  +21.216  51.657
 x.ns.gin.ntt.ne   2 u   15   64    7   53.703  +23.776  51.615
 toc.ntp.telstra   2 u   10   64    7    6.101  +19.268  51.533
 ntp1.ds.network  4 u   16   64    7    7.038  +21.764  51.995
 pauseq4vntp2.da   2 u   13   64    7   55.383  +22.052  51.303
 ntp.seby.io    2 u   15   64    7   51.082  +20.947  51.853
 y.ns.gin.ntt.ne   2 u   16   64    7   53.568  +25.298  52.200
 time.cloudflare        3 u   13   64    7    6.581  +19.633  52.201
 61-68-38-238.st     3 u   11   64    7    6.414  +18.791  52.401
 ec2-13-55-50-68   3 u   12   64    7   47.739  +19.313  51.808
 eth817.qld.adsl    2 u   12   64    3   73.448  +19.447  33.210   .PPS.            1 u   16   64    3   72.347  +21.210  31.913 (d    2 u   19   64    1   51.149  +21.280   0.000

[root@wr-fw ~]# cat /etc/ntp.conf
disable monitor
restrict default nomodify
pool 0.au.pool.ntp.org
pool 1.au.pool.ntp.org
pool 2.au.pool.ntp.org
pool 3.au.pool.ntp.org
fudge stratum 10
driftfile /etc/ntp/drift

Hi all,

all right, let’s shed some light on this…

This is completely intentional. Please refer to the NTP Pool Project’s homepage for further information on how the NTP pool architecture works.

ntpd sometimes gets confused if the internet connectivity is flapping. Because of this and some other reasons, we decided to move on to chrony, being a more robust software with a smaller footprint. Unfortunately, time is currently short, and priorities laid elsewhere (kernel 5.10.x in particular).

Thanks, and best regards,
Peter Müller