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)?
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+.
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.
-----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-d9feb4cde195...) 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
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
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 ;-)
- -- Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab
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-d9feb4cde195...) 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?
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
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...
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-d9feb4cde195...)
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...
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-d9feb4cde195...)
So I followed the instructions for installing chrony and then looked at /var/log/messages:
Dec 20 07:31:14 c2-c7 systemd: Reloading. Dec 20 07:31:15 c2-c7 systemd: Configuration file /usr/lib/systemd/system/auditd.service is marked world-inaccessible. This has no effect as configuration data is accessible via APIs without restrictions. Proceeding anyway. Dec 20 07:31:15 c2-c7 systemd: Configuration file /usr/lib/systemd/system/ebtables.service is marked executable. Please remove executable permission bits. Proceeding anyway. Dec 20 07:31:15 c2-c7 systemd: Configuration file /usr/lib/systemd/system/wpa_supplicant.service is marked executable. Please remove executable permission bits. Proceeding anyway. Dec 20 07:31:16 c2-c7 yum[2264]: Installed: chrony-2.1.1-1.el7.armv7hl
What is THIS all about? Sounds not so good....
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
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
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 ;-)
Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux)
iEYEARECAAYFAlZ2ZAIACgkQnVkHo1a+xU4nDgCeIKsrSOTzJuW/XRNluPQOKEtr C50AnifqBqHt1QoMH7diW+dVqWCqmhyI =hmZ7 -----END PGP SIGNATURE----- _______________________________________________ Arm-dev mailing list Arm-dev@centos.org https://lists.centos.org/mailman/listinfo/arm-dev
-
Fabian Arrotin -
Robert Moskowitz