Description of problem: Activating ntpd in MCC is not made permanent. The "Enable Network Time Protocol" checkbox in the "Manage date and time" function of Mageia Control Centre's "Systems" group indicates that ntpd is not active, whether it is or not. Version-Release number of selected component (if applicable): drakconf 12.22.1-2.mga2 How reproducible: Always, since an update a couple of weeks ago Steps to Reproduce: 1.Start MCC, choose Systems->Manage date and time 2.Activate ntpd using checkbox provided, select suitable server pool for your timezone 3.Click on OK to apply. If this is a fresh boot, ntpd will not be running before you do the above. After doing this, repeating step 1 will show that the checkbox is clear, but you can verify that ntpd is running. On re-boot, repeating step 1 will show ntpd is not running and you can verify that this is so. To verify, use "ps -C ntpd" or similar.
can be a bug result of fix of bug 3068 what is the output of : systemctl status ntpd.service ls /etc/systemd/system/*.wants/ntpd.service is ntpd running at boot if you do: systemctl enable ntpd.service ?
Source RPM: (none) => drakxtools
[root@Saucepan richard]# systemctl status ntpd.service ntpd.service - Network Time Service Loaded: loaded (/lib/systemd/system/ntpd.service; enabled) Active: active (running) since Sun, 05 Feb 2012 12:35:50 +0000; 53s ago Main PID: 1973 (ntpd) CGroup: name=systemd:/system/ntpd.service â 1973 /usr/sbin/ntpd -n -u ntp:ntp -g Feb 05 12:35:50 Saucepan.Studio ntpd[1973]: 0.0.0.0 c01d 0d kern kernel time sync enabled Feb 05 12:35:50 Saucepan.Studio ntpd[1973]: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16 Feb 05 12:35:50 Saucepan.Studio ntpd[1973]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123 Feb 05 12:35:50 Saucepan.Studio ntpd[1973]: Listen normally on 1 lo 127.0.0.1 UDP 123 Feb 05 12:35:50 Saucepan.Studio ntpd[1973]: Listen normally on 2 eth0 10.0.0.6 UDP 123 Feb 05 12:35:50 Saucepan.Studio ntpd[1973]: peers refreshed Feb 05 12:35:50 Saucepan.Studio ntpd[1973]: Listening on routing socket on fd #19 for interface updates Feb 05 12:35:51 Saucepan.Studio ntpd[1973]: 0.0.0.0 c016 06 restart Feb 05 12:35:51 Saucepan.Studio ntpd[1973]: 0.0.0.0 c012 02 freq_set kernel -3.045 PPM Feb 05 12:35:51 Saucepan.Studio ntpd[1973]: 0.0.0.0 c515 05 clock_sync
I feel slightly embarrassed now. That was 53 seconds after booting and yes, ntpd is running. The checkbox in MCC is still clear though. In my defence I can only say that until I moved my PC 85 miles to the south-west on Friday, the clock would always be an hour or more slow on the first boot of the day and I was in the habit of using MCC to enable ntpd which corrected the error. I have now replaced the battery on the circuit board. The other difference is that the PC is only "shut down, power off" while I am here. During the week it is always shutdown and unplugged from the electricity supply. It was the large discrepancy in the system time (now fixed) which drew my attention to the MCC ntpd checkbox state. Richard
CC: (none) => marja11, remco
I have not all understant but it seems resolved right ? So closing, and feel free to reopen, thanks.
Status: NEW => RESOLVEDResolution: (none) => INVALID
Sorry for confusing the issue. The problem still exists. I do wonder, though, why you do not see it too. I am using the latest Cauldron, fully updated as of 10 minutes ago. The absence of a tick in the MCC time setting section is quite clear. The server list is also "unset", even though I have Enabled network time protocol and selected uk.pool.ntp.org I checked bug 3068 too. It looks to be the same thing, at least insofar as the failure of MCC to work in the normal way is concerned. Richard
Status: RESOLVED => REOPENEDResolution: INVALID => (none)
There doesn't seem to be any likelihood of action on this bug so I will just live with it. *** This bug has been marked as a duplicate of bug 3068 ***
Status: REOPENED => RESOLVEDResolution: (none) => DUPLICATE
Richard, This bug is still on my todo list. As this bug has been marked a duplicate, further discussion can take place on that bug report. Kind regards, Remco