After a fresh cauldron install on my laptop yesterday, I noticed that the system clock was an hour off. I suspect this isn't ntpd, but I don't know enough about what the install and MCC do about setting the date and time to make a better guess. The install configured the timezone in Summary, setting the zone as America/New York, and checking "use ntpd" with the default of all servers. After a couple of reboots, I noticed that the clock did not reflect the recent change to Daylight Savings time. Thinking that perhaps ntpd came up and gave up before the wireless network had started, I restarted ntpd, but this had no effect. I checjed via the "date" command as well as the desktop display. I fired up MCC's Set Date and Time, and it showed the same wrong time. What finally fixed it was deselecting ntpd, closing MCC, reopening it, and re-selecting ntpd. This probably has something to do with the fact that both sysvinit and now systemd consider the activation of the unplaugged eth0 port to constitute "network up", and don't wait to start ntpd (and other things) until the working wireless network is really up. But it probably also means that the install, system initialization, and the MCC date/time utility are out of sync with each other on how configuration files ought to be written. I suspect that reactivating ntpd in drakclock caused a config file rewrite that set things right.
any ideas ?
CC: (none) => ennael1, guillomovitch, luigiwalserSource RPM: ntpd => ntp
CC: (none) => thierry.vignaud
Now the UK has changed to daylight saving time, I've also encountered this bug. The cause is that by default ntpd will not adjust the time if the difference between the system clock and the network clock exceeds 1000 seconds. From /var/log/syslog: ntpd[723]: 0.0.0.0 0617 07 panic_stop +3600 s; set clock manually within 1000 s. systemd[1]: ntpd.service: main process exited, code=exited, status=255 systemd[1]: Unit ntpd.service entered failed state. There are two ways to fix this: 1) Run ntpdate before starting the ntpd daemon 2) Start ntpd with the '-g' option The SysVinit script for ntpd supports both of these. The systemd config for ntpd does neither.
CC: (none) => mageia
Correction - the systemd config does use the '-g' option, but it doesn't seem to have the desired effect. More investigation required.
Nice catch Martin. I set up a Cauldron VM at work on Friday and I noticed that ntpdate.service was disabled, so I wondered if that meant it didn't run ntpdate before starting ntpd like the sysvinit script did. Would this bug be fixed if ntpdate.service was simply enabled?
Created attachment 1844 [details] Extract of ntpd messages from syslog Good thinking David. Enabling the ntpdate service does fix the bug for me. This bug appears to be system dependent. It is 100% repeatable on my desktop machine, but does not occur on my notebook. I've just updated both machines, and the problem persists. Note that on the notebook, it takes 5-10 minutes before the time is corrected, so this still isn't desirable behaviour. I've attached an extract from /var/log/syslog on my desktop machine, showing the messages from ntpd with debug enabled, in case this helps.
Looks like it first started trying to start ntpd before the network interface was up, so resolving the DNS names of your NTP servers didn't work. Then the interface came up so that worked, but then ntpd didn't respect the -g option (maybe because of the first problem). Enabling ntpdate.service forces it to be after network.service in the service ordering, but one would think ntpd.service would do this itself too.
Maybe this is why Fedora switched to using chrony by default. It's supposed to be able to handle this stuff better. Maybe we can try it for Mageia 3. In the meantime, I've updated ntp to hopefully enable ntpdate as well, so maybe this will fix it. DrakX/drakxservices (both in the installer and MCC) should probably also enable ntpdate when enabling ntpd, but I'm not sure how that's handled.
Well done everybody. Thanks for addressing this. If memory serves, there have been long-standing periodic complaints about ntpd starting before the network is available and then not recognizing when it actually is available. Some of this seems to be in the past, because when witeless is having trouble coming up, I see ntpd reacting as the wlan0 interface comes and goes. There are some services for which the network is desirable, but which have to eventually start regardless. Then there are others which are useless without the network. Do we have two separate systemd targets for these, and if so, is ntpd using the correct one ?
I just submitted a better fix for this, based on a similar change to some ssh service files in Fedora, which Colin Guthrie pointed out to me: http://pkgs.fedoraproject.org/gitweb/?p=openssh.git;a=commitdiff;h=52f99b131ac1d73c5a3cbf988b1f709cae2bb4a7;hp=33e0acc5efc7bce1620cc6841b4d453d668fa782
Is there anything else that needs to be done here, or can this be closed?
I'll try a fresh install and see if it's fixed.
Looks fine on a fresh install in VirtualBox.
Status: NEW => RESOLVEDResolution: (none) => FIXED
This appears broken again on a fresh install fromFriday.
Status: RESOLVED => REOPENEDResolution: FIXED => (none)
(In reply to comment #13) > This appears broken again on a fresh install fromFriday. Actually, it is broken in a different way. The timezone was set to New York (correct), but the time read four hours earlier than it should. I first suspected a GMT/local mixup (New York is GMT-4), but going through the above procedure corrected it once again. David, if you can verify that your fix is still in place, I'll close this again and open a new bug if i can get it to reoccur.
Yes, nothing has changed in ntpd. Please file a new bug.
like https://bugs.mageia.org/show_bug.cgi?id=5851 ?
(In reply to comment #16) > like https://bugs.mageia.org/show_bug.cgi?id=5851 ? Looks identical. I'll post there.
Status: REOPENED => RESOLVEDResolution: (none) => FIXED