From nobody Mon Oct 17 17:03:57 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MrjyM28z6z4ZxdV for ; Mon, 17 Oct 2022 17:04:11 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MrjyL1yMTz3c0F for ; Mon, 17 Oct 2022 17:04:10 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ed1-x533.google.com with SMTP id e18so16967246edj.3 for ; Mon, 17 Oct 2022 10:04:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=X1SdIAuOwz51njV+UMn/na0NcpioucX9E6/mMNqLYxU=; b=it22lOkbh3U8mzHfWUaD6mZ/6J0P9nNzi313DDMRDupJQxRSE+2TIWmaxgTcwUJHql TowYQvNOf4HrnDI7rBsEutOm/EJ25JupGceHyByeER8XcsRBVKNVUeOYXO6/RRYtks8r cG/cXri9zNaSZYt2klrIsnrpXv4c8VpiXrIF8eP1ll6daKWXIkTVIeCiNjKaNe19A4Xb UxOYrVpCKr0jq/w3b5rHpsx7Q0ZUlIiyVmTX29b6y5D9mdP3Pj4PNefomWOdb6zYrF53 jcZCRPCqiYRUi7SVBe2A0TDJ32C35Q8qMw7M3h/bYq0m8G0XBrYoTY5IaGv1t9dz/FuF l2Sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=X1SdIAuOwz51njV+UMn/na0NcpioucX9E6/mMNqLYxU=; b=J37OaxNaDQ2fWGsVqAGk2nubqC7InlhyWWZiROkV6yQfpGg50pjjIe6aWXGOHzuKWL 3IzU/hsZnelYjtpvO33si1V5g1NvcwiKO0KKYPzzyeOTKDMXT1I1GxPvHqNtU3l+eBqC bLjsmQESxf4eIBMnkq5T9zsh8PJKEtAELdlrpZfa1WwDPZb5zv7N1hvrdvsc7LJfSh7w /+j74HClxbX/cozD91LME/V5FluqTRVJ7xcZ3/PuTS4+cdEKm+Gs56QaY4Lupkxm4x3M B8ODhXdISGH9Iqv6iwvdfcoGfLedypJuvtLdVypoOqbctLtrK8rZFnJYUJ4yjDbed3tf pijw== X-Gm-Message-State: ACrzQf2Y+Gf76NzjAMYvadnNp+aw7UeQ4hw2+5fpLAxCSlXeEpOvnnd6 dpdF/LEBOZHmNbAOTTXYRLN4IA8RVATfT83/IhVSU/U9U6bkEQ== X-Google-Smtp-Source: AMsMyM7RNvqCOGo2MGqpJjfs8DZWgtoWCRFRyTfRUudqIxT42vWiYJ/jK7vdO0mXsvrEyM4N+TWUagFhSRpb0ebCZJU= X-Received: by 2002:a05:6402:2687:b0:45d:3a94:348f with SMTP id w7-20020a056402268700b0045d3a94348fmr11147274edd.48.1666026248878; Mon, 17 Oct 2022 10:04:08 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Mon, 17 Oct 2022 11:03:57 -0600 Message-ID: Subject: Re: host unresponsive when setting time very far in the future To: Michael Schuster , FreeBSD Hackers Content-Type: multipart/alternative; boundary="000000000000c05b6305eb3df67c" X-Rspamd-Queue-Id: 4MrjyL1yMTz3c0F X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=it22lOkb; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::533) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FREEMAIL_TO(0.00)[gmail.com,freebsd.org]; R_SPF_NA(0.00)[no SPF record]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; ARC_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::533:from]; DMARC_NA(0.00)[bsdimp.com]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --000000000000c05b6305eb3df67c Content-Type: text/plain; charset="UTF-8" On Mon, Oct 17, 2022 at 7:26 AM Jan Schaumann wrote: > Michael Schuster wrote: > > > On Mon, Oct 17, 2022, 04:10 Jan Schaumann > 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


=
On Mon, Oct 17, 2022 at 7:26 AM Jan S= chaumann <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.=C2=A0 (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 implie= d)?

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.=C2=A0 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=C2=A0 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 i= n 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 yea= r (tm_year) overflows an int (32-bit signed), we'll
have prob= lems. It would be approximately year=C2=A02,147,483,648 (since I think
the limitation is signed, not unsigned, but if unsigned it's=C2= =A04294967296 instead).
Anything beyond that we know definitely w= on'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...=C2=A0

<= div>Warner
--000000000000c05b6305eb3df67c--