*** Bug 17563 has been marked as a duplicate of this bug. ***

CC: (none) => westel

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.

CC: (none) => anaselli

Well, David, you're the one who comitted the support for chrony, so you should be able to debug it...

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

Priority: release_blocker => Normal

David, please tell if you need help with this bug report.

David can you give a real testcase ? so i can test and confirm it works ( or not ;) )

CC: (none) => mageia

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?

Thierry pushed a new systemd that tries to disable systemd-timedated but the build failed.

(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?

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 :-(

(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?

(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 ).

iirc  timedatectl status should show
NTP enabled: no
maybe also if not any ntp server is running
NTP synchronized: no

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).

(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.

why can't you fix in drakclock ? would be nice :)

(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?

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