No valid NTP replies received, check server and network connectivity

General Beta 6.0
1

Randomly seeing this on my Raspi everytime time i Reboot:

image
image746×133 3.39 KB

image

Debug Token URL: https://tricorder.pi-hole.net/NbRQsMgn

2

What version of Pihole 6 are you running?

pihole -v

also

pihole-FTL --config ntp
3

Always uptodate:

pihole:/# pihole -v
Core
    Version is b22731c (Latest: null)
    Branch is development-v6
    Hash is b22731c6 (Latest: b22731c6)
Web
    Version is 9d8a3df (Latest: null)
    Branch is development-v6
    Hash is 9d8a3dfc (Latest: 9d8a3dfc)
FTL
    Version is vDev-1dbd955 (Latest: null)
    Branch is development-v6
    Hash is 1dbd9556 (Latest: 10e98d1d)
pihole:/# pihole-FTL --config ntp
ntp.ipv4.active = true
ntp.ipv4.address = 
ntp.ipv6.active = true
ntp.ipv6.address = 
ntp.sync.active = true
ntp.sync.server = pool.ntp.org
ntp.sync.interval = 3600
ntp.sync.count = 8
ntp.sync.rtc.set = true
ntp.sync.rtc.device = 
ntp.sync.rtc.utc = true
pihole:/#
4

I think the FTL has a newer version

try pihole -up.

I haven't updated myself yet but it supposed to have a workaround

5

im running the docker version, so its not recommend to update inside the docker container itself.

My error message looks differen to the one you linked?

1 Like
6

What does your compose / run look like, and have you pulled the latest version of the development-v6 tag? (I think it builds nightly)

There was some code added to FTL to not start the NTP client if the container does not have the right capability (i.e SYS_TIME) - which it does not by default

image
image1092×576 44.4 KB

Else you should see something like this:

image
image881×692 52 KB

What does the container startup log look like? Up to just after FTL has started...

7

Hey,

looks like its working now. Maybe the new image from today morning fixed it!

But to answer your questions, i use these im my compose:

    cap_add:
    - SYS_TIME
    - NET_ADMIN
    - CAP_SYS_NICE

and in the log it looks all good with no Error in the GUI:

2024-07-20 10:26:45.689 CEST [151/T153] INFO: Compiled 0 allow and 0 deny regex for 21 clients in 1.3 msec

2024-07-20 10:26:49.711 CEST [151/T152] INFO: Received 8/8 valid NTP replies from pool.ntp.org

2024-07-20 10:26:49.711 CEST [151/T152] INFO: Time offset: 1.653016e+00 ms (excluded 0 outliers)

2024-07-20 10:26:49.711 CEST [151/T152] INFO: Round-trip delay: 1.475418e+01 ms (excluded 0 outliers)

2024-07-20 10:26:50.000 CEST [151/T168] INFO: NTP server listening on 0.0.0.0:123 (IPv4)

2024-07-20 10:26:50.000 CEST [151/T169] INFO: NTP server listening on :::123 (IPv6)
8

Think this should just be SYS_NICE, btw :slight_smile:

But glad a pull sorted it!

9

Oh well, i think both work and have the same function.

The log was saying this when none was used:

2024-07-20 10:45:43.051 CEST [151M] WARNING: Insufficient permissions to set process priority to -10 (CAP_SYS_NICE required), process priority remains at 0

2024-07-20 10:45:43.053 CEST [151M] INFO: PID of FTL process: 151

Thats why i just had uses the CAP Version, but using just SYS_NICE also works :slight_smile:
and looks better :smiley:

1 Like
10

Actually docker accepts both formats.

Docker normalizes capability names, adding the CAP_ prefix when missing.

From Docker Docs:

The --cap-add and --cap-drop flags accept capabilities to be specified with a CAP_ prefix. The following examples are therefore equivalent:

 docker run --cap-add=SYS_ADMIN ...

 docker run --cap-add=CAP_SYS_ADMIN ...
1 Like
11

Got it.
Yes, I have noticed at least 2-3 different messages depending on the platform .