Date: Mon, 17 Oct 2022 06:35:14 +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_gKvkhf6_N2UaZkxzcTau7Ewt%2BWBcx5=6aVmwC-BV_vbyA@mail.gmail.com> In-Reply-To: <Y0y5cDu5aT/kLkuR@netmeister.org> References: <Y0y5cDu5aT/kLkuR@netmeister.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--000000000000292cde05eb33813b Content-Type: text/plain; charset="UTF-8" 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 > > --000000000000292cde05eb33813b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto"><div>Jan,=C2=A0<br><br><div class=3D"gmail_quote"><div di= r=3D"ltr" class=3D"gmail_attr">On Mon, Oct 17, 2022, 04:10 Jan Schaumann &l= t;<a href=3D"mailto:jschauma@netmeister.org">jschauma@netmeister.org</a>>= ; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .= 8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br> <br> I've observed that trying to set the date _very_ far<br> in the future causes my FreeBSD AWS instance to become<br> unresponsive and requiring a forced reboot to come<br> back.=C2=A0 (I don't see an actual kernel panic, however.)<br></blockqu= ote></div></div><div dir=3D"auto"><br></div><div dir=3D"auto">A few questio= ns that come to mind:</div><div dir=3D"auto">- Which version of FreeBSD?=C2= =A0</div><div dir=3D"auto">- which architecture (I know nothing of AWS, per= haps that's implied)?=C2=A0</div><div dir=3D"auto">- have you tried thi= s on a different platform (a VM or real HW)?=C2=A0</div><div dir=3D"auto"><= br></div><div dir=3D"auto">Out of curiosity: why? :-)=C2=A0</div><div dir= =3D"auto"><br></div><div dir=3D"auto">One thing I'd do in a situation l= ike this is display the numbers in hex, that may give you a clue.=C2=A0</di= v><div dir=3D"auto"><br></div><div dir=3D"auto">HTH=C2=A0</div><div dir=3D"= auto">Michael=C2=A0</div><div dir=3D"auto">PS: make sure to keep the list i= ncluded, this about the extent of what I can add here!=C2=A0</div><div dir= =3D"auto"><br></div><div dir=3D"auto"><div class=3D"gmail_quote"><blockquot= e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol= id;padding-left:1ex"> <br> # date -f "%s" 44093078356492799<br> Fri Dec 31 23:59:59 UTC 1397255999<br> <br> succeeds, but any second more (i.e., into the year<br> 1397256000), and the system locks up.<br> <br> After setting the date as above and waiting a few<br> seconds does increment the seconds since epoch just<br> fine into the year 1397256000:<br> <br> # date +%s<br> 44093078356492850<br> # date<br> Sat Jan=C2=A0 1 00:00:51 UTC 1397256000<br> <br> so gettimeofday(2) has no problem with these numbers,<br> but it seems that settimeofday(2) does tickles the<br> kernel in a funny way?<br> <br> What's the significance of this particular year?=C2=A0 If<br> tm_year is a 32-bit entity, then I'd expect it to max<br> out at epoch 67768036191676799 aka 12/31 23:59:59<br> 2147485547, but that doesn't seem to be the case here.<br> <br> Any ideas (a) what this limit is, and (b) why the<br> system doesn't handle it gracefully by e.g., returning<br> EINVAL?<br> <br> -Jan<br> <br> </blockquote></div></div></div> --000000000000292cde05eb33813b--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CADqw_gKvkhf6_N2UaZkxzcTau7Ewt%2BWBcx5=6aVmwC-BV_vbyA>