# Issue with registration of a test NTP Pool Agent version v4.1.4 **URL:** \ **Category:** Monitoring Operators\ **Tags:** monitoring, beta\ **Created:** [April 24, 2026, 8:51am UTC](https://community.ntppool.org/t/issue-with-registration-of-a-test-ntp-pool-agent-version-v4-1-4/4365 "2026-04-24T08:51:38Z")\ **Posts on this page:** 12\ **Page:** 1
**Author:** ![NTPman](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/ntpman/32/450_2.png) [@NTPman](https://community.ntppool.org/u/NTPman)\ **Post date:** [April 24, 2026, 8:51am UTC](https://community.ntppool.org/t/issue-with-registration-of-a-test-ntp-pool-agent-version-v4-1-4/4365/1 "2026-04-24T08:51:38Z")
My issue is on aarch64, Raspberry PI 4 with Tumbleweed as OS, but I do not think that matters. Seting-up a new test monitor, `sudo journalctl -u ntppool-agent@\* -f` gives: ```auto Apr 24 08:44:40 tumbleweed.home ntppool-agent[51010]: level=WARN msg="no API key, please run ntppool-agent setup" env=test cmd="ntppool-agent setup --env test --state-dir '/var/lib/ntppool-agent'" wait_time=4m59s Apr 24 08:44:43 tumbleweed.home ntppool-agent[51010]: level=WARN msg="failed to refresh JWT token" env=test appconfig-manager.err="no API key available for JWT token request" ``` and that is normal. However, the next step `sudo -u ntpmon ntppool-agent setup -e test -a 355n9ds` gives a 404 error: ```auto tumbleweed:~ # sudo -u ntpmon ntppool-agent setup -e test -a 355n9ds time=2026-04-24T08:01:30.440Z level=INFO msg="using hostname for registration" env=test hostname=tumbleweed.home default backend - 404 tumbleweed:~ # ``` ---
**Author:** ![avij](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/avij/32/197_2.png) [@avij](https://community.ntppool.org/u/avij)\ **Post date:** [April 24, 2026, 9:46am UTC](https://community.ntppool.org/t/issue-with-registration-of-a-test-ntp-pool-agent-version-v4-1-4/4365/2 "2026-04-24T09:46:45Z")
This message from a configured test monitor may be related: level=WARN msg=“failed to reload AppConfig” env=test appconfig-manager.err=“unexpected response code: 404 (trace )” Other than that message my test monitors seem to be working fine.. Oh, or maybe not, because I also get: Apr 24 09:29:53 level=INFO msg=“certificate expiring, request renewal” env=test nextCheck=2h0m0s Apr 24 09:31:54 level=INFO msg=“certificate expiring, request renewal” env=test nextCheck=2h0m0s Apr 24 09:33:54 level=INFO msg=“certificate expiring, request renewal” env=test nextCheck=2h0m0s Apr 24 09:35:54 level=INFO msg=“certificate expiring, request renewal” env=test nextCheck=2h0m0s Apr 24 09:37:55 level=INFO msg=“certificate expiring, request renewal” env=test nextCheck=2h0m0s When the certificate actually expires in around 1h 20m the agent might start having problems communicating. We’ll see. But yes, there are issues, it seems. > openssl x509 -in /var/lib/ntppool-agent/test/cert.pem -text -noout | grep Not > Not Before: Apr 19 11:03:34 2026 GMT > Not After : Apr 24 11:04:04 2026 GMT > date > Fri Apr 24 09:44:01 UTC 2026 ---
**Author:** ![avij](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/avij/32/197_2.png) [@avij](https://community.ntppool.org/u/avij)\ **Post date:** [April 24, 2026, 10:09am UTC](https://community.ntppool.org/t/issue-with-registration-of-a-test-ntp-pool-agent-version-v4-1-4/4365/3 "2026-04-24T10:09:15Z")
Looks like (re)starting the agent does not work at the moment: ```auto systemd[1]: Started ntppool-agent@test.service - NTP Pool Monitor (test). ntppool-agent: level=INFO msg="certificate expiring, request renewal" env=test nextCheck=2h0m0s ntppool-agent: level=INFO msg="load failed" env=test err="unexpected response code: 404 (trace )" ntppool-agent: Usage: ntppool-agent monitor --env=test [flags] ntppool-agent: run monitor ntppool-agent: Flags: ntppool-agent: -h, --help Show context-sensitive help. ntppool-agent: --debug Enable debug logging ntppool-agent: --log-level="info" Log level for stderr (debug, info, warn, error) ntppool-agent: ($MONITOR_LOG_LEVEL) ntppool-agent: --state-dir=STRING Directory for storing state ($MONITOR_STATE_DIR) ntppool-agent: -e, --env=test Deployment environment (prod, test, devel) ntppool-agent: ($DEPLOYMENT_MODE) ntppool-agent: --[no-]ipv4 IPv4 monitor (default) ntppool-agent: --[no-]ipv6 IPv6 monitor (default) ntppool-agent: --once Only run once instead of forever ntppool-agent: --sanity-only Only run the local sanity check ntppool-agent: ntppool-agent: error: unexpected response code: 404 (trace ) systemd[1]: ntppool-agent@test.service: Main process exited, code=exited, status=1/FAILURE systemd[1]: ntppool-agent@test.service: Failed with result 'exit-code'. ``` This seems to affect only the test environment so it’s not the end of the world, but it’s still worth fixing, of course. ---
**Author:** ![MagicNTP](https://avatars.discourse-cdn.com/v4/letter/m/858c86/32.png) [@MagicNTP](https://community.ntppool.org/u/MagicNTP)\ **Post date:** [April 24, 2026, 10:50am UTC](https://community.ntppool.org/t/issue-with-registration-of-a-test-ntp-pool-agent-version-v4-1-4/4365/4 "2026-04-24T10:50:08Z")
Most of my test monitors are being reported as being disconnected since 2026-04-22. Only two were still connected. Just restarted one of them as part of updating the ntpool-agent package, and it’s now gone as well. So I guess as long as a back-end connection was still active since before the current outage on beta, it’ll keep working. But once it needs to be re-established, e.g., due to agent restart, or newly established (as during registration), the daemon will refuse to run due to the inability to successufully connect with the back-end. It will be interesting to see whether the upcoming expiry of the certificate will also break the connection. I guess as long as it tries to obtain a new certificate over an existing connection, it might be fine. But should it get a new certificate and try to re-establish the connection, that might break things. Except that it seems not unlikely that once the certificate renewal starts working again, also the other issue currently preventing connections would be solved as well - assuming both have the same underlying likely cause of systems not yet being properly interconnected again after the recent migration of the beta clusters (and many other things before that) to new infrastructure. ---
**Author:** ![avij](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/avij/32/197_2.png) [@avij](https://community.ntppool.org/u/avij)\ **Post date:** [April 24, 2026, 11:19am UTC](https://community.ntppool.org/t/issue-with-registration-of-a-test-ntp-pool-agent-version-v4-1-4/4365/5 "2026-04-24T11:19:03Z")
Repeating much of what MagicNTP wrote above, but as I had this message already prepared I’ll paste it here anyway: Ho hum, nothing happened when the certificate expired. I had left this test agent instance running, waiting for the cert to expire (the server where I tried to restart the agent was a different one). So this instance will keep testing for now. But I get it, the agent keeps a connection open all the time and the cert gets checked only when establishing the connection. Restarting the service would probably trigger a certificate check. But restarting the service would currently fail anyway due to the issue mentioned above. Restarting the agent that was already failing to start up (my previous message) but with a certificate that had expired in the meantime gave me this: level=INFO msg=“certificate expiring, request renewal” env=test nextCheck=2h0m0s level=INFO msg=“load failed” env=test err=“unexpected response code: 404 (trace )” I had expected some other error than a 404. Maybe renewing the certificate does not need a valid certificate? ---
**Author:** ![NTPman](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/ntpman/32/450_2.png) [@NTPman](https://community.ntppool.org/u/NTPman)\ **Post date:** [April 24, 2026, 1:38pm UTC](https://community.ntppool.org/t/issue-with-registration-of-a-test-ntp-pool-agent-version-v4-1-4/4365/6 "2026-04-24T13:38:10Z")
It looks like the backend has started now, so I can continue adding the test monitor. The next issue, may be I should open another topic for that? The nearest airport (~10 km) is missing from the list of airports that I could select for the name of the monitor. ---
**Author:** ![avij](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/avij/32/197_2.png) [@avij](https://community.ntppool.org/u/avij)\ **Post date:** [April 24, 2026, 3:56pm UTC](https://community.ntppool.org/t/issue-with-registration-of-a-test-ntp-pool-agent-version-v4-1-4/4365/7 "2026-04-24T15:56:05Z")
Maybe a new topic for the airport codes would be nice. I don’t think that mechanism has changed during this ongoing service move. Reading [this message](https://community.ntppool.org/t/beta-system-monitoring-testing/3875/43) first may be informative. As for this test monitor, I now get: level=ERROR msg=“could not get config, http error” env=test ip\_version=v4 err=“unavailable: tls: failed to verify certificate: x509: certificate is valid for localhost, ingress.local, not api.test.mon.ntppool.dev” so something is still not quite working. Edit: Additionally, api.test.mon.ntppool.dev has an IPv6 address as well but that seems to refuse connections. ---
**Author:** ![avij](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/avij/32/197_2.png) [@avij](https://community.ntppool.org/u/avij)\ **Post date:** [April 24, 2026, 4:30pm UTC](https://community.ntppool.org/t/issue-with-registration-of-a-test-ntp-pool-agent-version-v4-1-4/4365/8 "2026-04-24T16:30:51Z")
Also these messages: level=ERROR msg=“batch processing” env=test err=“getting server list: unavailable: tls: failed to verify certificate: x509: certificate is valid for localhost, ingress.local, not api.test.mon.ntppool.dev” level=INFO msg=“detected certificate/connection error, flushing connection pool” pool-flusher.url=[https://api.test.mon.ntppool.dev/monitor.v2.MonitorService/GetServers](https://api.test.mon.ntppool.dev/monitor.v2.MonitorService/GetServers) pool-flusher.error=“tls: failed to verify certificate: x509: certificate is valid for localhost, ingress.local, not api.test.mon.ntppool.dev” Many test monitors seem to be unable to phone home now, based on the plots on e.g. [194.100.49.152](https://web.beta.grundclock.com/scores/194.100.49.152). ---
**Author:** ![avij](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/avij/32/197_2.png) [@avij](https://community.ntppool.org/u/avij)\ **Post date:** [April 24, 2026, 7:19pm UTC](https://community.ntppool.org/t/issue-with-registration-of-a-test-ntp-pool-agent-version-v4-1-4/4365/9 "2026-04-24T19:19:54Z")
Hmm.. The graph may be misleading in this situation because the newest (rightmost) plots are actually fairly old already. The graph adjusts the timescale based on the timestamps of the available measurements with the newest available measurement always on the right edge of the graph. If no new measurements come in, the graph does not change. The [CSV](https://web.beta.grundclock.com/scores/194.100.49.152/log?limit=200&monitor=*) tells the truth – the data from the monitors stopped flowing at around 12:42:16, ie. 6.5 hours ago. * * * EDIT: I would have written a new message, but “An error occurred: No more than 3 consecutive replies are allowed. Please edit your previous reply, or wait for someone to reply to you.” What I meant to say: Looks like the certificate problem is fixed now and test monitors can send their measurements again. EDIT2: IPv6 address of api.test.mon.ntppool.dev is still unreachable, though. ---
**Author:** ![ask](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/ask/32/907_2.png) [@ask](https://community.ntppool.org/u/ask)\ **Post date:** [April 26, 2026, 1:04am UTC](https://community.ntppool.org/t/issue-with-registration-of-a-test-ntp-pool-agent-version-v4-1-4/4365/10 "2026-04-26T01:04:39Z")
Hi everyone, apologies for the lack of updates. I wanted to get ready to move the production site this weekend so I moved the beta site over some evenings in the last week; and then had some busy work days and a 17 hour flight so I didn’t realize until later (thanks for the messages here!) that renewed certificates didn’t work. I’d prepared and tested the certificate authority flip back in December, but … didn’t deploy the updated API server. 🙄 Oops. I’m fixing the IPv6 access to the API IP now. ---
**Author:** ![ask](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/ask/32/907_2.png) [@ask](https://community.ntppool.org/u/ask)\ **Post date:** [April 26, 2026, 1:09am UTC](https://community.ntppool.org/t/issue-with-registration-of-a-test-ntp-pool-agent-version-v4-1-4/4365/11 "2026-04-26T01:09:09Z")
I think anything in your analysis here was accurate. 🙂 @NTPman The airport name issue could be related to the move, or a random timing of a MaxMind update maybe. I haven’t changed the [locationcode](https://gitea.develooper.com/ask/locationcode) tool for a while. ---
**Author:** ![NTPman](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/ntpman/32/450_2.png) [@NTPman](https://community.ntppool.org/u/NTPman)\ **Post date:** [June 3, 2026, 11:30am UTC](https://community.ntppool.org/t/issue-with-registration-of-a-test-ntp-pool-agent-version-v4-1-4/4365/12 "2026-06-03T11:30:07Z")
> [@ask](#): > > The airport name issue could be related to the move, or a random timing of a MaxMind update maybe. About a month elapsed, the move is finished, and it looks like the MaxMind database still does not offer the nearest airport to my location (~10 Km). Is it possible to enable the free selection of airport code into the monitor name?