On 09/02/2015 10:29 AM, Dennis Gilmore wrote:
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
Using timedatectl to check things, I noticed:
# timedatectl
Local time: Wed 2015-09-02 14:05:18 UTC
Universal time: Wed 2015-09-02 14:05:18 UTC
RTC time: Thu 1970-01-01 00:20:40
Timezone: n/a (UTC, +0000)
NTP enabled: yes
NTP synchronized: yes
RTC in local TZ: no
DST active: n/a
but even with rtcsync enabled, the RTC time is always running at epoch
start time. So perhaps there is an rtc, with no battery. But it is not
getting synced from the system by chrony.
For some reason, SoC makes consider the space for a battery as too
expensive.
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.
Right. Once connected. And if connection is not there at start, but
comes up later (you forgot to turn on the ethernet switch), it takes
perhaps 5min after ip is enabled until the time is corrected.
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.
True, but I can come up with lots of cases of no internet and needing
some sense of time.
I would really like to know the use cases where chronyd is not sufficient and
the problems that people are trying to solve.
Consider your system controls your house security. External power and
internet are off due to a storm, but you have internal power (like that
Telsa wall battery). For some reason your system rebooted and now it
comes up with date of 1-1-1970. Not so good.
Your system is in your car. It powers up when the car is started.
Internet access is only available when it is in your garage or your
phone has internet. You are on vacation in the woods, no internet on
your phone. No accurate or even approximate time on your system? Not
so good.
Yes, these are edge cases. But they will occur and we need to handle
them properly. rtc batteries are currently rare on arm boards, it
seems. It appears there are tools that mostly work; they should be enabled.
_______________________________________________
arm mailing list
arm@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/arm
