| Re: [chrony-users] NTP signd socket status logging enhancement |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-users Archives
]
On 2023-10-05 09:23, Miroslav Lichvar wrote:
On Wed, Oct 04, 2023 at 08:42:10AM -0400, Jeremy Jackson wrote:
https://gitlab.com/chrony/chrony/-/merge_requests/3
I spent longer than I should have troubleshooting a typo in a config file, so I thought I'd contribute a logging enhancement that could save others (including my future self, heh) some time.
Transitions in status of running Samba AD process are also reflected in log messages.
I think that reported error in the initial connection could be
confusing to users as chronyd is normally not ordered in the boot
after samba and would likely be failing.
Perhaps gentler wording would be appropriate? If not, I guess sysadmin could infer the same thing from the lack of a connection success message. I guess I could also filter out the case of an existing unix socket, with proper permissions, that just isn't accepting connections, from all the other error conditions, that aren't dependent on state of Samba running or not.
I guess the chronyc status commands could show this state connected/failing instead.
Requests from clients shouldn't be able to trigger an informational
log message to avoid flooding the syslog. There already is an error
reported for failed connect as a debug message.
I considered that, and I believe the logic would only allow 1 message on each transition, regardness of the number of client requests. So it would only be Samba socket availabilty changes that would trigger the log message. I suppose if Samba failing and recovering quickly being the cause of log flooding is a concern, a rate limit could be set? But it seems like there are bigger problems if that is the case.
I suppose another avenue would be to let the sysadmin view dropped requests, and seeing that those are due to lack of ntp-signd socket.
The general principle I'm aiming for, is that problems due to samba not running, permission errors, config file errors, should be made obvious, and shouldn't require tcpdump, debug logs, reading source code, and other low level approaches.
Stil, it's pretty nice to have a working NTP that requires zero config for Windows clients.
--
To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.