Date: Mon, 17 Oct 2022 08:02:38 +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_gL-m8F8fsMeYh_SO0ccyuUZU=f_gfSa4XcZNO5FAcpJeA@mail.gmail.com> In-Reply-To: <CADqw_gKvkhf6_N2UaZkxzcTau7Ewt%2BWBcx5=6aVmwC-BV_vbyA@mail.gmail.com> References: <Y0y5cDu5aT/kLkuR@netmeister.org> <CADqw_gKvkhf6_N2UaZkxzcTau7Ewt%2BWBcx5=6aVmwC-BV_vbyA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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'
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CADqw_gL-m8F8fsMeYh_SO0ccyuUZU=f_gfSa4XcZNO5FAcpJeA>