On Wednesday, September 02, 2015 03:46:55 PM Miroslav Lichvar wrote:
On Wed, Sep 02, 2015 at 08:51:17AM -0400, Robert Moskowitz wrote:
> OH?!? I am running F22 with Xfce, last updated Aug 23. So whatever is in
> there wrt systemd-timesyscd and chronyd is what was in the image orginally
> plus whatever happened when I did the date/time config in the graphic
> configurator as part of the install (I go in and change my city from NYC
> to
> Detroit). A quick check shows:
>
> So it seems both are present, but only chronyd is running.
The chrony package is installed by default and the time configuration
tool is enabling/disabling the chronyd service (via timedatex). To
start timesyncd on boot you can either run "systemctl disable chronyd"
and "systemctl enable timesyncd", or uninstall the chrony and
timedatex packages and disable and enable the NTP checkbox again in
the time config.
> I made these changes. In /etc/chrony.conf I now have:
>
> # Enable kernel synchronization of the real-time clock (RTC).
> #rtcsync
> rtcdevice /dev/nonexist
>
> I commented out the rtcsync line, given you told me to add the nonexist
> line. Hope that is correct.
That shouldn't matter, if there is no battery for the RTC, there is
probably no point in trying to keep the RTC synchronized.
> Perhaps these settings should be standard in our armv7 builds? Or an easy
> option to set them. A check box for 'no rtc' on that configurator?
Maybe anaconda could do that. How common is to have a Fedora ARM
machine without an RTC and how common it is to have an RTC, but no
battery?
Every arm device I have used has a rtc, but a very large number of them
have
no battery. some have two rtc devices and teh battery backed one ends up on
/dev/rtc1
There is also a possibility to restore the time from a file in a
separate service, without having to run an NTP client. On Debian,
it's done by the fake-hwclock service. For Fedora there seems to be a
Copr repo with it. I didn't try it.
https://copr.fedoraproject.org/coprs/jorti/fake-hwclock/
chronyd in my use has always set the time correctly as soon as it has a
working network connection.
any attempt to set the time based on something in the filesystem is going to
result in the time being off. if it is something baked in at compose or image
creation time the drift will get bigger over time. if it is some service that
sets it on shutdown the drift will be small. network is required to get it
accurate.
I would really like to know the use cases where chronyd is not sufficient and
the problems that people are trying to solve.
Dennis