[Arm-dev] We need to consider system time

[Robert Moskowitz]

On 12/20/2015 06:26 AM, Robert Moskowitz wrote:
>
>
> On 12/20/2015 03:17 AM, Fabian Arrotin wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 20/12/15 04:12, Robert Moskowitz wrote:
>>> Most armv7 boards lack a battery to maintain system time.  On
>>> firstboot they come up a zero time.  This results in the initial
>>> log files (and other key files) to have a zero date:
>>>
>>> # ls /var/log/ -lst total 260 84 -rw-------. 1 root root 82722 Dec
>>> 19 21:45 messages 8 -rw-------. 1 root root   4889 Dec 18 16:27
>>> secure 16 -rw-------. 1 root root  14517 Dec 18 16:01 cron 4
>>> drwx------. 2 root root   4096 Dec 18 00:38 httpd 24 -rw-------. 1
>>> root root  19279 Dec 18 00:37 yum.log 0 -rw-------. 1 root root
>>> 0 Dec  3 09:07 spooler 0 -rw-------. 1 root root      0 Dec  3
>>> 09:05 tallylog 4 drwx------. 2 root root   4096 May 28  2015 ppp 4
>>> -rw-------. 1 root utmp   1152 Dec 31  1969 btmp 16 -rw-rw-r--. 1
>>> root utmp  13824 Dec 31  1969 wtmp 4 -rw-------. 1 root root    200
>>> Dec 31  1969 maillog 28 -rw-r--r--. 1 root root 292292 Dec 31 1969
>>> lastlog 4 drwxr-xr-x. 2 root root   4096 Dec 31  1969 tuned 4
>>> -rw-r--r--. 1 root root    120 Dec 31  1969 wpa_supplicant.log 4
>>> drwxr-x---. 2 root root   4096 Dec 31  1969 audit 8 -rw-r--r--. 1
>>> root root   8180 Dec 31  1969 boot.log 24 -rw-r--r--. 1 root root
>>> 23322 Dec 31  1969 dmesg 24 -rw-r--r--. 1 root root  23322 Dec 31
>>> 1969 dmesg.old
>>>
>>>
>>> Logwatch will have problems with these files (or that has been my
>>> prior experience).  I suspect other services will have problems
>>> with such 'old' files on the system.
>>>
>>> First we need to select the time management service:  ntp or
>>> timesync (I think I got this service naed correctly)?
>> chronyd is the way tto go for el7, reason why I added it on the wiki
>> page
>> (https://wiki.centos.org/SpecialInterestGroup/AltArch/Arm32#head-d9feb4cde1956642a4a4e36b81a7e17b53a30805) 
>>
>> and it seems to work for me on a reboot :
>>
>> Jan 01 01:00:23 rpi2 chronyd[187]: System clock wrong by
>> 1450599058.242734 seconds, adjustment started
>> Dec 20 09:11:21 rpi2 chronyd[187]: System clock was stepped by
>> 1450599058.242734 seconds
>
> OK.  that 'looks' good, but then chronyd needs to be in your base 
> image so it is there for firstboot. Not 2nd boot, at best.  ;)
>
> Time syncing is not a niceity on a batteryless Arm board like it is on 
> a typical Intel board.  Hopefully this occurs 'soon enough' that we do 
> not have log files and others with bad dates.
>
> I will read up on chronyd to see if there is a way to seed it with a 
> date from a file.  But perhaps others here already know how to do this?
>

I have installed chrony and tested and did get a quick adjustment of the 
system time, as long as there is network connection.  Of course right 
now I am using DHCP, so if I pull the network cable, nothing happens 
until I cable up.  A proper test would be using a static IP and link up, 
but no routing to the Internet and see what happens. After reading the 
man on chrony[.conf] and chrony.txt, I don't see a way to 'easily' have 
it figure out that needs to get a time from somewhere other than the 
network.  Bummer.

I tested out fixing file dates with 'touch' and once you add chrony to 
the base image, I will see what files in /var/log (don't know where else 
to look) get decent dates.


>>
>>
>>
>>> Fedora is using timesync and gets the current proper time from the
>>>   network shortly after bootup.  But there are some problems with
>>> this that are not so much an issue for a desktop, but are for a
>>> server.
>>>
>>> The firstboot timestamping problem I show above still occurs.
>>> Fedora has a later version of timesync that has this function.  The
>>>   version in Centos7 does not. What happens when a server restarts
>>> after a power outage, but before the external network access is
>>> available?  For some time the system runs with time zero+.
>> True, as chronyd will need access to network (early in the boot
>> process , through systemd) for that change .. we can investigate
>> another way of doing that

My feable attempts to read through this, are indeed feable.  But I 
wonder if this belongs in chrony.conf on a system without a battery RTC?

# Enable kernel RTC synchronization.
rtcsync

Can't figure out which direction this works...

>>
>>> Here is what I am thinking as the way to address this:
>>>
>>> The time services have the ability to read a file for a date hint
>>> if the date is less than some set time, or that is what I
>>> understand. So add to the centos-arm-installer script (to be made
>>> for the fedora-arm-installer script) a set to get the date from the
>>> installing system and pushing it into the proper place of the
>>> centos7-arm image.
>>>
>>> Now at first boot, the system SHOULD come up with this date which
>>> is at least a good start that will tend to not be too stale.
>>>
>>> Next this date file should be updated through some automatic
>>> process so in the event that a system is turned off then reboots,
>>> it comes up with a rather good start time.
>>>
>>> I don't know what would be a good way to do this on Centos7. I can
>>>   search back in my various discussions on this subject on a couple
>>> of lists.  But there are people here that I hope are better able to
>>> make the design decisions needed so that our Centos7-armv7 systems
>>> have good time.
>>>
>> Keep us informed ;-)
>
> I do tend to do that...