Date: Mon, 17 Oct 2022 11:03:57 -0600 From: Warner Losh <imp@bsdimp.com> To: Michael Schuster <michaelsprivate@gmail.com>, FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: host unresponsive when setting time very far in the future Message-ID: <CANCZdfpduEOSZiYJboAHiuPZJvvieM3w68QY2QhxowcsEibxvA@mail.gmail.com> In-Reply-To: <Y01X%2B6cY2fdLzbqg@netmeister.org> References: <Y0y5cDu5aT/kLkuR@netmeister.org> <CADqw_gKvkhf6_N2UaZkxzcTau7Ewt%2BWBcx5=6aVmwC-BV_vbyA@mail.gmail.com> <Y01X%2B6cY2fdLzbqg@netmeister.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--000000000000c05b6305eb3df67c Content-Type: text/plain; charset="UTF-8" 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 --000000000000c05b6305eb3df67c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">= <div dir=3D"ltr" class=3D"gmail_attr">On Mon, Oct 17, 2022 at 7:26 AM Jan S= chaumann <<a href=3D"mailto:jschauma@netmeister.org">jschauma@netmeister= .org</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"mar= gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1= ex">Michael Schuster <<a href=3D"mailto:michaelsprivate@gmail.com" targe= t=3D"_blank">michaelsprivate@gmail.com</a>> wrote:<br> <br> > On Mon, Oct 17, 2022, 04:10 Jan Schaumann <<a href=3D"mailto:jschau= ma@netmeister.org" target=3D"_blank">jschauma@netmeister.org</a>> wrote:= <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= > > ><br> > <br> > A few questions that come to mind:<br> > - Which version of FreeBSD?<br> > - which architecture (I know nothing of AWS, perhaps that's implie= d)?<br> <br> This was on AMI ami-00e91cb82b335d15f, from the<br> official 13.0R announcement, amd64.<br> <br> > - have you tried this on a different platform (a VM or real HW)?<br> <br> No, I don't have those immediately available.<br> <br> But I just now tried on ami-0cf377776fddcf8ba, which<br> is amd64 / 13.1R, where setting the date to<br> 44093078356492800 succeeds.=C2=A0 However, there the<br> problem appears at 49282253052249598 epoch:<br> <br> <br> # date -f "%s" 49282253052249598<br> Fri Dec 31 23:59:58 UTC 1561694399<br> # date -f "%s" 49282253052249599<br> Fri Dec 31 23:59:59 UTC 1561694399<br> [ reboots ~three seconds later ]<br> <br> I see a message in the logs that dhclient core dumped:<br> <br> Jan=C2=A0 1 00:00:14 freebsd kernel: pid 499 (dhclient),<br> jid 0, uid 0: exited on signal 6 (core dumped)<br> <br> but that doesn't directly lead to the system<br> rebooting.<br> <br> What's funny is is that after setting the date to<br> 49282253052249598, it will continue to run just fine,<br> even as the time advanced beyond the time at which it<br> reboots when explicitly set.<br> <br> > Out of curiosity: why? :-)<br> <br> Exactly that: out of curiosity. :-)<br> <br> > One thing I'd do in a situation like this is display the numbers i= n hex,<br> > that may give you a clue.<br> <br> In this case, I think the numbers point to the<br> tm_year, as in both cases it's at the year end, it<br> seems to me.<br></blockquote><div><br></div><div>We do know that if the yea= r (tm_year) overflows an int (32-bit signed), we'll</div><div>have prob= lems. It would be approximately year=C2=A02,147,483,648 (since I think</div= ><div>the limitation is signed, not unsigned, but if unsigned it's=C2= =A04294967296 instead).</div><div>Anything beyond that we know definitely w= on't work. Why we fall short</div><div>and "only" make it to = year 1.561,694,399, I don't know the root</div><div>cause of. It's = not even a nice, round multiple of the above...=C2=A0</div><div><br></div><= div>Warner</div></div></div> --000000000000c05b6305eb3df67c--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfpduEOSZiYJboAHiuPZJvvieM3w68QY2QhxowcsEibxvA>