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

On Mon, Oct 17, 2022 at 7:26 AM Jan Schaumann <jschauma@netmeister.org>
wrote:

> Michael Schuster <michaelsprivate@gmail.com> wrote:
>
> > On Mon, Oct 17, 2022, 04:10 Jan Schaumann <jschauma@netmeister.org>
> wrote:
>
> > > 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)?
>
> This was on AMI ami-00e91cb82b335d15f, from the
> official 13.0R announcement, amd64.
>
> > - have you tried this on a different platform (a VM or real HW)?
>
> No, I don't have those immediately available.
>
> But I just now tried on ami-0cf377776fddcf8ba, which
> is amd64 / 13.1R, where setting the date to
> 44093078356492800 succeeds.  However, there the
> problem appears at 49282253052249598 epoch:
>
>
> # date -f "%s" 49282253052249598
> Fri Dec 31 23:59:58 UTC 1561694399
> # date -f "%s" 49282253052249599
> Fri Dec 31 23:59:59 UTC 1561694399
> [ reboots ~three seconds later ]
>
> I see a message in the logs that dhclient core dumped:
>
> Jan  1 00:00:14 freebsd kernel: pid 499 (dhclient),
> jid 0, uid 0: exited on signal 6 (core dumped)
>
> but that doesn't directly lead to the system
> rebooting.
>
> What's funny is is that after setting the date to
> 49282253052249598, it will continue to run just fine,
> even as the time advanced beyond the time at which it
> reboots when explicitly set.
>
> > Out of curiosity: why? :-)
>
> Exactly that: out of curiosity. :-)
>
> > One thing I'd do in a situation like this is display the numbers in hex,
> > that may give you a clue.
>
> In this case, I think the numbers point to the
> tm_year, as in both cases it's at the year end, it
> seems to me.
>

We do know that if the year (tm_year) overflows an int (32-bit signed),
we'll
have problems. It would be approximately year 2,147,483,648 (since I think
the limitation is signed, not unsigned, but if unsigned it's 4294967296
instead).
Anything beyond that we know definitely won't work. Why we fall short
and "only" make it to year 1.561,694,399, I don't know the root
cause of. It's not even a nice, round multiple of the above...

Warner