Bug 11502

Summary:	"Date And Time" settings and Cauldron: Network Time Protocol cannot be activated.
Product:	Mageia	Reporter:	Laurent Caruso <laurentcliff>
Component:	RPM Packages	Assignee:	Thierry Vignaud <thierry.vignaud>
Status:	NEW ---	QA Contact:
Severity:	normal
Priority:	Normal	CC:	alda.cerny, anaselli, davidwhodgins, fiable, lists.jjorge, luigiwalser, mageia, yvesbrungard
Version:	Cauldron
Target Milestone:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Source RPM:		CVE:
Status comment:

Description Laurent Caruso 2013-10-21 14:40:31 CEST

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:

Comment 1 Manuel Hiebel 2013-10-21 18:09:37 CEST

Looks this is a kde issue

CC: sysadmin-bugs => balcaen.john, lmenut
Component: Release (media or process) => RPM Packages
Assignee: bugsquad => nicolas.lecureuil
Summary: "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)

Comment 2 David Walser 2013-10-22 19:34:46 CEST

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

David Walser 2013-10-22 23:11:19 CEST

CC: (none) => luigiwalser

Comment 3 David Walser 2014-03-06 18:28:23 CET

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

Comment 4 Henri de Solages 2014-09-08 12:12:58 CEST

But adding 123/udp to the firewall GUI configuration doesn't solve the problem.

CC: (none) => fiable

Comment 5 José Jorge 2014-09-12 10:44:52 CEST

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

Comment 6 Angelo Naselli 2014-09-12 11:45:54 CEST

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

Comment 7 Henri de Solages 2015-03-28 06:43:17 CET

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.

Comment 8 papoteur 2019-05-27 10:18:00 CEST

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

Comment 9 Ales Cerny 2020-02-11 22:31:20 CET

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

Comment 10 Dave Hodgins 2020-02-12 01:23:22 CET

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

Comment 11 David Walser 2020-02-12 03:03:26 CET

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.