Closed jBRNDnl closed 1 month ago
Hello,
User that performs check should be in chrony
group. Other alternative is to use sudo -u chrony
.
However chronyc
somehow could connect to the daemon from any user, i will try to do the same if i have time.
@jBRNDnl any updates?
sudo
or sudo -u _chrony
didn't work. But sudo env "PATH=$PATH"
did. But now the output isn't exactly what I would have expected.
Check result.
2021/02/10 13:05:53 Tracking server: C0A8A82D (192.168.168.45)
2021/02/10 13:05:53 CRITICAL: 192.168.168.45 server LastRx: 975
2021/02/10 13:05:53 CRITICAL: <ntpserver#2> server LastRx: 288
2021/02/10 13:05:53 CRITICAL: <ntpserver#3> server LastRx: 840
2021/02/10 13:05:53 CRITICAL: <ntpserver#4> server LastRx: 1870
2021/02/10 13:05:53 WARNING: only 50.0% sources reachable!
chronyc> activity
200 OK
4 sources online
chronyc> sources
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^* 192.168.168.45 1 10 377 205 -103us[ -34us] +/- 13ms
^- <ntpserver#1> 1 10 377 558 -638us[ -580us] +/- 7861us
^- <ntpserver#2> 2 10 71 1110 -970us[ -931us] +/- 27ms
^- <ntpserver#3> 2 10 215 75 -716us[ -716us] +/- 28ms
Default -W
and -C
are small, tune them for your configuration.
WARNING: only 50.0% sources reachable!
Looks like only two servers responds with Reachability == 255.
Please run in --debug
mode to see what data check gets from chronyd.
I ran into the same problem as @jBRNDnl, but i am not able to solve the problem using the sudo hint (or the group membership or relaxing directory rights)
Strictly spoken, accessing the socket across user boundaries is an architectural flaw. chronyc uses IP communication if not startet by root or chrony.
The manpages of chronyc says:
There are two ways chronyc can access chronyd. One is the Internet Protocol (IPv4 or IPv6) and the other is a Unix domain socket, which is accessible locally by the root or chrony user. By default, chronyc first tries to connect to the Unix domain socket. The compiled-in default path is /run/chrony/chronyd.sock. If that fails (e.g. because chronyc is running under a non-root user), it will try to connect to 127.0.0.1 and then ::1.
Best solution would be to have an IPv4 communication in the plugin.
close as staling.
Hi,
How to overcome the following result after running: sensu-go-chrony-check?
Error executing sensu-go-chrony-check: error validating input: --socket error: lstat /var/run/chrony/chronyd.sock: permission denied
Best regards, John