avij
April 17, 2026, 7:31am
1
I’m not sure if this change is intended (it may or may not be), but ntppool-agent 4.1.3 is less verbose than 4.1.2 and older versions.
Before:
ntppool-agent[2643477]: level=INFO msg="batch processing" env=test ip_version=v4 monitor_ip=xxx count=1
ntppool-agent[2643477]: level=INFO msg="batch processing" env=test ip_version=v6 monitor_ip=xxx count=4
ntppool-agent[2643488]: level=INFO msg="ntp error" env=prod ip_version=v6 batchID=01KPD3YJ6BX5VC59F0R686QRA9 server=2a05:dfc1:3ccc:6fe6::123 err="network: i/o timeout"
ntppool-agent[2643488]: level=INFO msg="batch processing" env=prod ip_version=v6 monitor_ip=xxx count=8
ntppool-agent[2643488]: level=INFO msg="batch processing" env=prod ip_version=v4 monitor_ip=xxx count=30
ntppool-agent[2643477]: level=INFO msg="batch processing" env=test ip_version=v6 monitor_ip=xxx count=1
ntppool-agent[2643488]: level=INFO msg="batch processing" env=prod ip_version=v6 monitor_ip=xxx count=10
ntppool-agent[2643488]: level=WARN msg="dns lookup failed" env=prod ip_version=v6 host=uklon5-ntp-002.aaplimg.com err="lookup uklon5-ntp-002.aaplimg.com on 127.0.0.1:53: no such host" trace_id=41014188b08e6c847e9e57311bfd5ed2 span_id=a9368404cbd49289
ntppool-agent[2643488]: level=INFO msg="batch processing" env=prod ip_version=v4 monitor_ip=xxx count=28
ntppool-agent[2643477]: level=INFO msg="batch processing" env=test ip_version=v4 monitor_ip=xxx count=2
ntppool-agent[2643488]: level=INFO msg=local-check env=prod ip_version=v6 failures=0 threshold=3 hosts=7 trace_id=41014188b08e6c847e9e57311bfd5ed2 span_id=a9368404cbd49289
ntppool-agent[2643477]: level=INFO msg="batch processing" env=test ip_version=v4 monitor_ip=xxx count=2
ntppool-agent[2643488]: level=INFO msg="batch processing" env=prod ip_version=v4 monitor_ip=xxx count=12
Now:
ntppool-agent[2936471]: batch processing
ntppool-agent[2936471]: batch processing
ntppool-agent[2936471]: batch processing
ntppool-agent[2936471]: ntp error
ntppool-agent[2936471]: batch processing
ntppool-agent[2936471]: batch processing
ntppool-agent[2936471]: batch processing
ntppool-agent[2936471]: dns lookup failed
ntppool-agent[2936471]: batch processing
ntppool-agent[2936471]: local-check
ntppool-agent[2936471]: batch processing
ntppool-agent[2936471]: batch processing
ntppool-agent[2936471]: ntp error
So it looks like it’ll log only the “msg” part of the previous log message entries.
There’s now an even newer version available. 4.1.4. Do you still see the issue with that one?
I saw something similar recently, but had the impression it had been going on for a while already, so not sure it was related to 4.1.3, and now I can’t find it anymore to investigate…
I now have three monitors running on 4.1.4 (2x production, 1x test), and so far, all look ok to me…
avij
April 23, 2026, 4:30pm
3
4.1.4 seems to work OK and so did 4.1.2. Only 4.1.3 had this issue.
Marking this issue as solved.
ask
April 26, 2026, 1:21am
4
Thanks @avij .
@MagicNTP had pointed out (elsewhere) that the agent wasn’t very collaborative with basic journald features. I fixed that in 4.1.3, but it got a bit “too collaborative” in hiding the log attributes in journald meta-data. In 4.1.4 I added them back as part of the text (they should still be attributes as well for filtering etc).
# NTP Pool Monitor Changes
## v4.1.4
### Client
- **Journald improvements**: Pick up upstream `go.ntppool.org/common` v0.10.2 with better systemd journal support
### Tests
- Stop client/config tests from depending on the live devel API; route HTTP through an in-process fake and add a tripwire test that fails if any test reaches an external network
## v4.1.3
### Client
- **Systemd journal integration**
When stderr is connected to journald, log records are delivered via the native journal protocol with per-record `PRIORITY=`, so `journalctl -p` and `LogLevelMax=` in the unit file filter by severity. `DEBUG_INVOCATION` (from `RestartMode=debug`) automatically raises stderr verbosity to debug on a failed-restart attempt.
- **MQTT session takeover backoff**
When the broker reports a session takeover (reasonCode `0x8E`), the agent escalates the reconnect backoff (2m → 5m → 10m → 15m) instead of reconnecting on the 10s default, and pauses NTP checks and result submission while another client holds the session. The backoff resets after 30 minutes of stable connection. The disconnect reasonCode is now always logged.
## v4.1.2
This file has been truncated. show original
Bas
April 27, 2026, 5:19pm
5
Is there a reason why APT sticks to 4.1.2?
I did and apt update/upgrade of Debian Trixie but it doesn’t upgrade to a newer level.
avij
April 27, 2026, 5:34pm
6
Versions 4.1.3 and above are currently only available in the testing repositories. For Debian, it’s probably ntppool-test . 4.1.2 is currently the newest version that is in the production repos.
alica
April 28, 2026, 5:21am
7
So how can I download official binary without rpm/deb? The former download site is no longer active, and I cannot find direct download link from Gemfury repo . After all I can only upgrade my agent binary by building it myself…
You could download the RPM or deb package and extract the binary from there if the need is urgent.
ask
April 29, 2026, 10:34am
9
Hi @alica – the release process (in .woodpecker and scripts/) need to create a small html page or some such at a fixed path.
For now the latest release (4.1.5) is here – replace the filename with the relevant filename from the text file: https://builds.ntppool.dev/ntppool-agent/builds/release/29/checksums.txt
ask
April 29, 2026, 10:36am
10
Also, 4.1.5 release notes and 4.1.3 (.4 was a bug-fix to the journald feature in .13 as described above).
alica
May 3, 2026, 2:22pm
11
Did not find the actual cause, but the official Linux i386 binary is not run-able on my non-SSE2 machine, while my build from Github v4.1.5 tag works… All I did to cross compile in Raspberry Pi is:
GOOS=linux GOARCH=386 GO386=softfloat go build ./cmd/ntppool-agent