My Centos7 system does not have a battery for the clock (like most armv7 SOCs), thus I rely on that at some point in boot time, chronyd sets the time. If a file is updated prior to chronyd accomplishing its task (or network connectivity is down), the file ends up with a timestamp of "Dec 31 1969".
I notice that occasionally, after a reboot, /etc/aliases.db reverts to this time, and I have to run newaliases to fix it. I suppose I could run touch as well.
What process could be rebuilding aliases.db? Postfix list says it isn't them.
How, after chronyd, can I insure the date on aliases.db is not back to 0?
Yes, this is just a warning message in maillog, but annoying.
thanks
Got what I needed from the chronyd list
On 04/20/2017 10:00 AM, Robert Moskowitz wrote:
My Centos7 system does not have a battery for the clock (like most armv7 SOCs), thus I rely on that at some point in boot time, chronyd sets the time. If a file is updated prior to chronyd accomplishing its task (or network connectivity is down), the file ends up with a timestamp of "Dec 31 1969".
I notice that occasionally, after a reboot, /etc/aliases.db reverts to this time, and I have to run newaliases to fix it. I suppose I could run touch as well.
What process could be rebuilding aliases.db? Postfix list says it isn't them.
How, after chronyd, can I insure the date on aliases.db is not back to 0?
Yes, this is just a warning message in maillog, but annoying.
"The recommended way to delay start of a service until the clock is synchronized is to add "After=time-sync.target" to its unit file and enable the chrony-wait service. It uses the chronyc waitsync command to delay the time-sync target."
-
Robert Moskowitz