Date: Mon, 17 Oct 2022 06:35:14 +0200 From: Michael Schuster <michaelsprivate@gmail.com> To: Jan Schaumann <jschauma@netmeister.org> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: host unresponsive when setting time very far in the future Message-ID: <CADqw_gKvkhf6_N2UaZkxzcTau7Ewt%2BWBcx5=6aVmwC-BV_vbyA@mail.gmail.com> In-Reply-To: <Y0y5cDu5aT/kLkuR@netmeister.org> References: <Y0y5cDu5aT/kLkuR@netmeister.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] Jan, On Mon, Oct 17, 2022, 04:10 Jan Schaumann <jschauma@netmeister.org> wrote: > Hello, > > I've observed that trying to set the date _very_ far > in the future causes my FreeBSD AWS instance to become > unresponsive and requiring a forced reboot to come > back. (I don't see an actual kernel panic, however.) > A few questions that come to mind: - Which version of FreeBSD? - which architecture (I know nothing of AWS, perhaps that's implied)? - have you tried this on a different platform (a VM or real HW)? Out of curiosity: why? :-) One thing I'd do in a situation like this is display the numbers in hex, that may give you a clue. HTH Michael PS: make sure to keep the list included, this about the extent of what I can add here! > # date -f "%s" 44093078356492799 > Fri Dec 31 23:59:59 UTC 1397255999 > > succeeds, but any second more (i.e., into the year > 1397256000), and the system locks up. > > After setting the date as above and waiting a few > seconds does increment the seconds since epoch just > fine into the year 1397256000: > > # date +%s > 44093078356492850 > # date > Sat Jan 1 00:00:51 UTC 1397256000 > > so gettimeofday(2) has no problem with these numbers, > but it seems that settimeofday(2) does tickles the > kernel in a funny way? > > What's the significance of this particular year? If > tm_year is a 32-bit entity, then I'd expect it to max > out at epoch 67768036191676799 aka 12/31 23:59:59 > 2147485547, but that doesn't seem to be the case here. > > Any ideas (a) what this limit is, and (b) why the > system doesn't handle it gracefully by e.g., returning > EINVAL? > > -Jan > > [-- Attachment #2 --] <div dir="auto"><div>Jan, <br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 17, 2022, 04:10 Jan Schaumann <<a href="mailto:jschauma@netmeister.org">jschauma@netmeister.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br> <br> I've observed that trying to set the date _very_ far<br> in the future causes my FreeBSD AWS instance to become<br> unresponsive and requiring a forced reboot to come<br> back. (I don't see an actual kernel panic, however.)<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">A few questions that come to mind:</div><div dir="auto">- Which version of FreeBSD? </div><div dir="auto">- which architecture (I know nothing of AWS, perhaps that's implied)? </div><div dir="auto">- have you tried this on a different platform (a VM or real HW)? </div><div dir="auto"><br></div><div dir="auto">Out of curiosity: why? :-) </div><div dir="auto"><br></div><div dir="auto">One thing I'd do in a situation like this is display the numbers in hex, that may give you a clue. </div><div dir="auto"><br></div><div dir="auto">HTH </div><div dir="auto">Michael </div><div dir="auto">PS: make sure to keep the list included, this about the extent of what I can add here! </div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br> # date -f "%s" 44093078356492799<br> Fri Dec 31 23:59:59 UTC 1397255999<br> <br> succeeds, but any second more (i.e., into the year<br> 1397256000), and the system locks up.<br> <br> After setting the date as above and waiting a few<br> seconds does increment the seconds since epoch just<br> fine into the year 1397256000:<br> <br> # date +%s<br> 44093078356492850<br> # date<br> Sat Jan 1 00:00:51 UTC 1397256000<br> <br> so gettimeofday(2) has no problem with these numbers,<br> but it seems that settimeofday(2) does tickles the<br> kernel in a funny way?<br> <br> What's the significance of this particular year? If<br> tm_year is a 32-bit entity, then I'd expect it to max<br> out at epoch 67768036191676799 aka 12/31 23:59:59<br> 2147485547, but that doesn't seem to be the case here.<br> <br> Any ideas (a) what this limit is, and (b) why the<br> system doesn't handle it gracefully by e.g., returning<br> EINVAL?<br> <br> -Jan<br> <br> </blockquote></div></div></div>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CADqw_gKvkhf6_N2UaZkxzcTau7Ewt%2BWBcx5=6aVmwC-BV_vbyA>