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