SOFTWARE VERSION Cauldron (KDE): Mageia-4-alpha3-x86_64-DVD.iso STEPS LEADING TO PROBLEM 1. Right-Click on the date (lower right part of the screen). 2. Select "Adjust Date and Time" 3. "Date, Clock and Time Zone settings" dialog is shown. Tick the option "Network Time Protocol" 4. select any NTP server from the list 5: Click on "OK" to confirm changes EXPECTED OUTCOME: NTP server can be enabled. The "Date, Clock and Time Zone settings" dialog is closed. Time changes according to NTP settings. ACTUAL OUTCOME: Clicking on "OK" doesn't do anything The Date, Clock and Time Zone settings dialog is still in focused. Changes are not taken into account. FREQUENCY OF OCCURENCE Always Reproducible: Steps to Reproduce:
Looks this is a kde issue
CC: sysadmin-bugs => balcaen.john, lmenutComponent: Release (media or process) => RPM PackagesAssignee: bugsquad => nicolas.lecureuilSummary: "Date And Time" settings and Cauldron: Network Time Protocol cannot be activated. => "Date And Time" settings and Cauldron: Network Time Protocol cannot be activated. (kde)
I don't think it's a KDE issue. I believe this is drakclock that gets used for this, and it might have been broken by recent changes.
CC: (none) => mageia
CC: (none) => luigiwalser
At work, NTP is blocked by the firewall. I don't know if that's a critical component of this, but I can confirm this behavior from drakclock. I'm thinking that after you hit OK and it pauses, maybe it's trying to sync and fails because of that, but I'm not sure. Unfortunately, drakclock doesn't let you manually enter your own NTP server. If you have ntp installed, it also fails if it can't sync, but at least it tells you that's the reason.
CC: balcaen.john, lmenut => (none)Summary: "Date And Time" settings and Cauldron: Network Time Protocol cannot be activated. (kde) => "Date And Time" settings and Cauldron: Network Time Protocol cannot be activated.Assignee: mageia => thierry.vignaud
But adding 123/udp to the firewall GUI configuration doesn't solve the problem.
CC: (none) => fiable
I don't know if this is the same problem, but looks like we hit a bug if the system clock differs from ntp serveur between 29 and 101 seconds : in this case, chronyd change 30 times the clock by one second every 10 seconds, then fails. This is easy to watch in drakclock terminal output.
CC: (none) => lists.jjorge
saying that manaclock is not drakclock, and neither is completed yet, (does not install any packages for ntp clients) could you please test it if manaclock behaves the same? To understand if it is the call to ntp synch the problem. TIA
CC: (none) => anaselli
At least, NTP should be on the list of "Set up your personal firewall" in Mageia control centre, with an explanation about what this protocol is for.
This problem is still valid. Console says for drackclock: Note: This output shows SysV services only and does not include native systemd services. SysV configuration data might be overridden by native systemd configuration. If you want to list systemd services use 'systemctl list-unit-files'. To see services enabled on particular target use 'systemctl list-dependencies [target]'. try: 1, refid: 0.0.0.0, correction: 0.000000000, skew: 0.000 try: 2, refid: 163.172.25.19, correction: 0.000226042, skew: 628.144 and closes. But coming again, ntp checkbox is still unticked. For manaclock, applying new settings ask for root credentials 2 times, but alerts that user has no credentials for settings.
CC: (none) => yves.brungard_mageia
the problem is in Mageia 7 still present, I have installed "chrony", but the problem is still there in console: # drakclock Note: This output shows SysV services only and does not include native systemd services. SysV configuration data might be overridden by native systemd configuration. If you want to list systemd services use 'systemctl list-unit-files'. To see services enabled on particular target use 'systemctl list-dependencies [target]'. 11 Feb 22:23:26 ntpd[5138]: ntpd 4.2.8p13@1.3847-o Fri Mar 29 13:48:38 UTC 2019 (1): Starting 11 Feb 22:23:26 ntpd[5138]: Command line: /usr/sbin/ntpd -gqc /dev/null cz.pool.ntp.org 11 Feb 22:23:26 ntpd[5138]: proto: precision = 0.048 usec (-24) 11 Feb 22:23:26 ntpd[5138]: line 0 column 0 syntax error, unexpected $end 11 Feb 22:23:26 ntpd[5138]: basedate set to 2019-03-17 11 Feb 22:23:26 ntpd[5138]: gps base set to 2019-03-17 (week 2045) 11 Feb 22:23:26 ntpd[5138]: Listen and drop on 0 v6wildcard [::]:123 11 Feb 22:23:26 ntpd[5138]: Listen and drop on 1 v4wildcard 0.0.0.0:123 11 Feb 22:23:26 ntpd[5138]: Listen normally on 2 lo 127.0.0.1:123 11 Feb 22:23:26 ntpd[5138]: Listen normally on 3 wlp3s0 192.168.2.15:123 11 Feb 22:23:26 ntpd[5138]: Listen normally on 4 lo [::1]:123 11 Feb 22:23:26 ntpd[5138]: Listen normally on 5 wlp3s0 [fd85:8273:51e4:0:c595:41c6:3b45:4258]:123 11 Feb 22:23:26 ntpd[5138]: Listen normally on 6 wlp3s0 [fe80::6842:35d4:5d0:d633%3]:123 11 Feb 22:23:26 ntpd[5138]: Listening on routing socket on fd #23 for interface updates 11 Feb 22:23:35 ntpd[5138]: ntpd: time slew -0.001691 s ntpd: time slew -0.001691s
CC: (none) => alda.cerny
Looks to me like the problem is in drakclock. If neither the package ntp or the package chrony has been installed, it will install the ntp package, but the rest of /usr/libexec/drakclock is only set up to configure and start the ntp service. So if chrony has been installed, drakclock fails to enable ntp usage. While chrony can be used instead of ntp, it must be manually configured rather then relying on drakclock. Workaround is to use ntp instead of chrony.
CC: (none) => davidwhodgins
The way it was supposed to work wad to prefer chrony if both or neither were installed, but use ntp if only it was installed, but it's not working as intended.