On 04/20/2017 05:16 PM, Warren Young wrote:
On Apr 20, 2017, at 3:00 PM, Robert Moskowitz <r...@htt-consult.com> wrote:
So I have learned that Postfix should delay until Chronyd has moved the system
time from 0 to current.
I think it’s more the case that CentOS is written with the assumption that
you’re running it on a host with a battery-backed RTC, so that system time
isn’t wildly off at boot time. This includes VMs, since the VM host should
pass its RTC through to the VM.
What are you running CentOS on that doesn’t have this property?
It is the Centos7 for arm SOCs. RPi is one of the worst (in my opinion)
of these. See:
http://medon.htt-consult.com/arm.html
The only such system I can think of which will also run CentOS is the Raspberry
Pi 3. They dropped the battery-backed RTC in the name of cost savings and that
most Pi boards are network-connected, so they can get Internet time soon after
boot. But yeah, there is a small window...
What other services need to be delayed?
I can only speculate. But take the above as a warning: lots of other software
may assume sane system time at startup. Short of a massive code audit or your
present “canvass the audience” approach, I don’t know how you find out which
ones.
Apache?
Just speculating here, but my sense is that Apache doesn’t care about dates and
times until it gets an HTTP request, in order to handle Expires headers and
such correctly. And, HTTP being stateless, even if an HTTP request comes in so
early that it gives the wrong answer, it should get back on track once the
system clock is fixed.
On the Apache list, I was just told
"There are some parts of the HTTP conversation which could be affected
by having the wrong time, but HTTPD itself doesn't care.
For example, if you are using cookies, caching, those could be affected
by the time change (even more specifically, for PHP sessions, when the
clock changes, the PHP session cleanup handler might think a session is
very old and remove it)."
Bind?
Similar to Apache, due to cache expiration rules. Since “now” minus time_t(0)
is $bignum, that means as soon as the system clock is fixed, it will expire all
the info it learned in the time the clock was wrong, and any info it gave out
with start time equal to 0 + epsilon will expire immediately in clients’ DNS
caches.
Since so much other software depends on having a local DNS server early in
their startup, I would definitely not delay BIND startup on any machine where
the local DNS configuration points to localhost.
_______________________________________________
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
_______________________________________________
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
