Re: host unresponsive when setting time very far in the future

From: Michael Schuster <michaelsprivate_at_gmail.com>
Date: Mon, 17 Oct 2022 06:02:38 UTC
to answer myself:

On Mon, Oct 17, 2022 at 6:35 AM Michael Schuster
<michaelsprivate@gmail.com> wrote:
>
> 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)?

on AMD-based HW from 2020, running 13.1-RELEASE-p2, I could not
duplicate OP's observation.

regards
>
> 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
>>


-- 
Michael Schuster
http://recursiveramblings.wordpress.com/
recursion, n: see 'recursion'