On 04/20/2017 05:16 PM, Warren Young wrote: > On Apr 20, 2017, at 3:00 PM, Robert Moskowitz <rgm at 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 at centos.org > https://lists.centos.org/mailman/listinfo/centos