Bug 885770

Description of problem:
Chrony can fail to set the hardware clock leading to incorrect time on boot, in my case off by one hour after a DST change.

Version-Release number of selected component (if applicable): 
chrony-1.27-0.3.pre1.fc17.x86_64

How reproducible: Always

Steps to Reproduce:
1. Set hardware clock to incorrect value.
2. reboot system

(Actual problem was likely a result of DST change not being written to HW, that
likewise could be reproduced, but requires more effort.)
  
Actual results:
The hardware clock remains at the set value, though system time is corrected.

Expected results:
Hardware clock adjusted to system time, or UTC if configured.

Additional info:

I only noticed this due to a sort of race condition, I have cacti polling from this machine on a one minute interval. chronyd starts before cron, but it did not complete the time adjustments before cron ran the poller script, which inserted a poller_lastrun value 45 minutes into the future into the cacti DB and stopping polling either until adjusted or 45 minutes had elapsed.

I looked for a chronyd file in /etc/sysconfig but it's use seems to have been depreciated when looking at rpm spec files and in it's systemd script so there seems to be no way to easily test changing it's startup options.

I installed adjtimex to see if it will be used, that is not clear in documentation I was able to locate, if it does perhaps this is just a packaging problem and adjtimex needs to be included when chronyd is installed?