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

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