<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 8, 2017 at 9:52 AM, Bob Harold <span dir="ltr"><<a href="mailto:rharolde@umich.edu" target="_blank">rharolde@umich.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><span class="gmail-"><div class="gmail_extra"><div><div class="gmail-m_493910612762713953gmail_signature"><br></div></div><div class="gmail_quote">On Tue, Aug 8, 2017 at 9:48 AM, Mike <span dir="ltr"><<a href="mailto:the.lists@mgm51.com" target="_blank">the.lists@mgm51.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>On 8/8/2017 8:39 AM, Eugene Grosbein wrote:<br>
> 08.08.2017 19:29, Pavel Zhukov wrote:<br>
><br>
>>>> I am experiencing an interesting problem with DHCP client timeouts.<br>
>>>> When the system boots up it set its date/time, starts DHCP client and NTP client.<br>
>>>> Only after the DHCP client interface is configured, the NTP client is able to access<br>
>>>> the NTP server.<br>
>>>> In my case, when NTP client adjusts the date/time it is set 12 hours back because<br>
>>>> of different time zone.<br>
>>><br>
>>> That's plain wrong and that's a root of your problem.<br>
>>> In no way a time zone difference should affect NTP time and kernel<br>
>>> time.<br>
>> Unfortunately it's not. Some systems keep local time in RTC.<br>
><br>
> They are asking for troubles. They should not do that.<br>
> dhcp code is not only one that would misbehave due to kernel time step back.<br>
><br>
>> Besides of that there are systems without RTC at all<br>
><br>
> Yes, and I have such system. They init kernel time with some constant in the past<br>
> at the boot time (like, 1 Jan 2000) and step time forward, not back.<br>
> So, they don't have this problem.<br>
<br>
<br>
</span>Perhaps a workaround in the OP's instance would be to run the date<br>
command early in the boot cycle (before DHCP and NTP start) and set the<br>
system time to some early value.  Then, when ntp finally starts up it<br>
will be a guaranteed jump forward.<br>
<div class="gmail-m_493910612762713953HOEnZb"><div class="gmail-m_493910612762713953h5"></div></div></blockquote></div><br></div></span><div class="gmail_extra">Good idea.  As an alternative, add a "dhcp renew" after ntp updates the time.  I think that might be safer.  Would that work?</div><span class="gmail-HOEnZb"><font color="#888888"><div class="gmail_extra"><br></div><div class="gmail_extra">-- </div><div class="gmail_extra">Bob Harold</div><div class="gmail_extra"><br></div></font></span></div>
</blockquote></div><br></div><div class="gmail_extra">If the clock change is because of dual-booting Windows (which sets the hardware clock to local time) and Linux (which sets the hardware clock to UTC), then there are solutions to make both operating systems set the hardware clock the same way.  Search for "linux windows dual boot system clock"</div><div class="gmail_extra"><br></div><div class="gmail_extra">-- </div><div class="gmail_extra">Bob Harold</div><div class="gmail_extra"><br></div></div>