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

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.

-Jan