Bug 17091 - drakclock should use chrony as default implementation, not systemd-timedated
: drakclock should use chrony as default implementation, not systemd-timedated
Status: NEW
Product: Mageia
Classification: Unclassified
Component: RPM Packages
: Cauldron
: i586 Linux
: Normal Severity: normal
: Mageia 6
Assigned To: Mageia tools maintainers
:
:
: MGA5TOO
: 6dev1
:
:
  Show dependency treegraph
 
Reported: 2015-11-05 15:40 CET by David Walser
Modified: 2017-01-17 10:37 CET (History)
6 users (show)

See Also:
Source RPM: drakxtools-16.104-1.mga5.src.rpm
CVE:
Status comment: No progress, risks becoming an errata entry if nothing is done.


Attachments

Description David Walser 2015-11-05 15:40:30 CET
When enabling ntp through drakclock, it currently messes up the system ntp configuration pretty badly.  It doesn't see that chrony is enabled and set up with an ntp server, so it defaults to an empty choice for the ntp server, and then it disables chrony and enables systemd-timedated, which doesn't work well.  It should use chrony by default, just as the installer does (and also fall back to ntpd if it's installed and chrony isn't).  It shouldn't be using systemd-timedated.

Reproducible: 

Steps to Reproduce:
Comment 1 Marja van Waes 2016-02-07 10:34:35 CET
*** Bug 17563 has been marked as a duplicate of this bug. ***
Comment 2 Angelo Naselli 2016-02-07 12:21:09 CET
I think it is also related to the bug found in last devel tests of mga5:
https://bugs.mageia.org/show_bug.cgi?id=15534
As far as i remember chronyd is the default, but systemd-timedated started anyway
conflicting and something was wrong because drakclock could not manage systemd-timedated. I haven't tested it right now, happy to see that it does now, so maybe that bug could be closed. FWIW manaclock manages the services that are installed, hopefully in the right way. It cannot add the package, if it is not installed, though yet.
Comment 3 Thierry Vignaud 2017-01-16 10:24:24 CET
Well, David, you're the one who comitted the support for chrony, so you should be able to debug it...
Comment 4 Thierry Vignaud 2017-01-16 10:30:04 CET
First, drakclock doesn't do anything systemd-timedate.
Secondly, being not able to re read back a value isn't critical.
Last but not least, it works for me in my tests
Comment 5 Samuel Verschelde 2017-01-16 10:31:05 CET
David, please tell if you need help with this bug report.
Comment 6 Nicolas Lécureuil 2017-01-16 10:33:20 CET
David can you give a real testcase ? so i can test and confirm it works ( or not ;) )
Comment 7 Angelo Naselli 2017-01-16 12:17:46 CET
Well the bugs quoted in this one are examples of the evidence of the problem, i'm not sure it is still the case nowadays though... Is systemd-timesyncd disabled during installation now?
Comment 8 Samuel Verschelde 2017-01-16 13:57:16 CET
Thierry pushed a new systemd that tries to disable systemd-timedated but the build failed.
Comment 9 David Walser 2017-01-16 15:09:10 CET
(In reply to Thierry Vignaud from comment #3)
> Well, David, you're the one who comitted the support for chrony, so you
> should be able to debug it...

If I could have fixed it myself I would have done so a long time ago.  Yes I need help with this.  The code looked correct when it was committed. 

So, have we reached the point in the release process where we decided that we're not going to fix anything and will just release it as-is?
Comment 10 Thierry Vignaud 2017-01-16 15:36:05 CET
I see you've decided to be very constructive today.
Here I told you that:
- your claims are wrong, drakclock doesn't do anything with systemd-timedated 
and you should know it as you altered the code
- it works in my testing
- I've fixed you unrelated issue with systemd-timedated where it belongs
  (aka in systemd)

It is very rewarding to get such answer as yours while fixing the bugs you report on my own free time....
Thank you very much :-(
Comment 11 Angelo Naselli 2017-01-16 15:55:39 CET
(In reply to Thierry Vignaud from comment #10)

> and you should know it as you altered the code
> - it works in my testing
> - I've fixed you unrelated issue with systemd-timedated where it belongs
>   (aka in systemd)

As far as i can say, using ntpd it would have been behave the same.

Said that i'd like to help, so please Thierry which is the right place in which you think it's better to fix this. in manaclock i disabled the systemd-timedated, but there i was able to know if it is running or not. Here we could disable it in any cases, but which could be the consequence, into the installer?
Comment 12 Nicolas Lécureuil 2017-01-16 16:45:07 CET
(In reply to Thierry Vignaud from comment #10)
> I see you've decided to be very constructive today.
> Here I told you that:
> - your claims are wrong, drakclock doesn't do anything with
> systemd-timedated 
> and you should know it as you altered the code
> - it works in my testing
> - I've fixed you unrelated issue with systemd-timedated where it belongs
>   (aka in systemd)
> 
> It is very rewarding to get such answer as yours while fixing the bugs you
> report on my own free time....
> Thank you very much :-(

your fix seems good to me, you didn't removed systemd-timedated just disabeld it by default.


how to test this ? Please tell me and i will do the QA ( as i have not yet updated to latest cauldron ).
Comment 13 Angelo Naselli 2017-01-16 17:10:53 CET
iirc  timedatectl status should show
NTP enabled: no
maybe also if not any ntp server is running
NTP synchronized: no
Comment 14 David Walser 2017-01-16 17:15:46 CET
Thierry, thank you for the fix in systemd.

Nicolas, from reading my initial report here, I think the best test case would be to do an installation and enable NTP in the installer (I believe that's through the Time Zone settings in the Summary screen), then on the installed system, run drakclock.  See if it shows NTP as enabled (if should) and enable it if not, and see what happens.

Other possible test cases on an existing Cauldron system would be to manually install the chrony package and then to run drakclock and see what happens there.  One way would be to do just that, another would be to edit /etc/chrony.conf and change the pool line to an actual server line before running drakclock (I don't believe our tools would recognize the new pool directive).
Comment 15 Angelo Naselli 2017-01-16 17:21:08 CET
(In reply to David Walser from comment #14)
> /etc/chrony.conf and change the pool line to an actual server line before
> running drakclock (I don't believe our tools would recognize the new pool
> directive).
If nobody has changed the code since my mail dated 9/10/2016 i would say it does not.
in manaclock the patch was:
http://gitweb.mageia.org/software/manatools/patch/?id=4b91d04b4228043cc2c77bf171683d10fa735f0c
but ican't work on it in drakclock sorry.
Comment 16 Nicolas Lécureuil 2017-01-16 18:41:23 CET
why can't you fix in drakclock ? would be nice :)
Comment 17 David Walser 2017-01-16 19:19:39 CET
(In reply to Nicolas Lécureuil from comment #16)
> why can't you fix in drakclock ? would be nice :)

He mentioned it in this comment:
https://bugs.mageia.org/show_bug.cgi?id=15534#c65

It sounds like maybe porting the fix to drakclock is non-trivial because the code is different?
Comment 18 David Walser 2017-01-16 19:23:56 CET
Thierry's fix in systemd should be good progress in fixing this.  Additionally it might be nice if drakclock could disable systemd-timesyncd if it happens to be enabled.

Other outstanding issues would be fixing our drakclock code to be able to handle the new pool directive in chrony.conf.

Other things to test to see if they're still broken:
https://bugs.mageia.org/show_bug.cgi?id=11092#c8
https://bugs.mageia.org/show_bug.cgi?id=11092#c9
https://bugs.mageia.org/show_bug.cgi?id=11502

Note You need to log in before you can comment on or make changes to this bug.