From nobody Mon Oct 17 04:35:14 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 4MrPLR6sNRz4fmlK for ; Mon, 17 Oct 2022 04:35:27 +0000 (UTC) (envelope-from michaelsprivate@gmail.com) Received: from mail-oi1-x234.google.com (mail-oi1-x234.google.com [IPv6:2607:f8b0:4864:20::234]) (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 4MrPLR1zFMz42HN for ; Mon, 17 Oct 2022 04:35:27 +0000 (UTC) (envelope-from michaelsprivate@gmail.com) Received: by mail-oi1-x234.google.com with SMTP id w196so10927135oiw.8 for ; Sun, 16 Oct 2022 21:35:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=kX1ZosbsbppmgTBVsLMlS182r4Z76U6HIETyfVLAfnI=; b=a//WjBGEZedVKbyGQhek/IV6hzIt26XvUZVL9JAfY4LAaRK3aK2PJj46OBFRQaHN3H 47HVBeLPbLxC6dXJFkmvQaVB85z75Mm+NBCg8rw0tGkgBMV6WNYkBthqrkXiEirp6Wi2 lHCOafjP2+kv7nDiBAvMWnp/aLH6TbyqlzRu3bhK0jYWMZeQpvm3eiWEioKm5tznce+v ne67bjUGqNrmwtSdR1ZPJvxJTvwXQNSTNMqbcaab3qRntwa6bE2uwqAP2f9UblaQblbx i4+sGbsOQLdsSvQVl3E8uKSLJ2RbwaakJmOKeU8RvK7Kaz1K4CYcSAybWOFfkr1WdZui +gZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc: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=kX1ZosbsbppmgTBVsLMlS182r4Z76U6HIETyfVLAfnI=; b=OfS93WcJsUSU62nNw/yPOa82kI9TyZmYyHGUqBWNUS8GT8wDeHHlUOfMuhQW9a2vFv nHIuAuVF5cXemcZlycCOz5Z1DjrSoO/jvIIDZXdpjCnVkvIsZl7MhslxspYsHphHXMaV bEkmf9rqXwQ2WLeIJUgVpLza5L/0L7ftBiPLaoh8XNDB1WxmEZfQg7IDs0Y5ajYK1ZFw +HxyMxhqvutGeqXpBfcGLxx4n1hKueNTxfgRbHmyJAku55yxtf9hpisPJiC/XdmDTqfc TjpUFMpeHClL+sxQ902QAQa5oeqDM59YZnUPiyxMYQRQkpS9YhyI1weNeRz4zA8j6Jem AYQA== X-Gm-Message-State: ACrzQf2Oiv4hw2qm8FGBl1hoCDjHyE6o/LfdvX8iHIDSx3N0r7J7SPK9 nmtR4a0Dhg8ERkVMqmUYO6KICU3PzF9ar7EtUx/5FvuZdnU= X-Google-Smtp-Source: AMsMyM6P2X9RmJdHBjKFMSIgHnPqfMfokxrghH++qvmEcuDNqjR0r8Z0f/tBqzqEluN5wntHzqJMksbuVPQo3F92lMc= X-Received: by 2002:a05:6808:993:b0:354:c979:46f6 with SMTP id a19-20020a056808099300b00354c97946f6mr11802342oic.141.1665981326369; Sun, 16 Oct 2022 21:35:26 -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: Michael Schuster Date: Mon, 17 Oct 2022 06:35:14 +0200 Message-ID: Subject: Re: host unresponsive when setting time very far in the future To: Jan Schaumann Cc: FreeBSD Hackers Content-Type: multipart/alternative; boundary="000000000000292cde05eb33813b" X-Rspamd-Queue-Id: 4MrPLR1zFMz42HN X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b="a//WjBGE"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of michaelsprivate@gmail.com designates 2607:f8b0:4864:20::234 as permitted sender) smtp.mailfrom=michaelsprivate@gmail.com X-Spamd-Result: default: False [-3.97 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.97)[-0.966]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ARC_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::234:from]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N --000000000000292cde05eb33813b Content-Type: text/plain; charset="UTF-8" Jan, On Mon, Oct 17, 2022, 04:10 Jan Schaumann 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
Jan,=C2=A0

On Mon, Oct 17, 2022, 04:10 Jan Schaumann &l= t;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.=C2=A0 (I don't see an actual kernel panic, however.)

A few questio= ns that come to mind:
- Which version of FreeBSD?=C2= =A0
- which architecture (I know nothing of AWS, per= haps that's implied)?=C2=A0
- have you tried thi= s on a different platform (a VM or real HW)?=C2=A0
<= br>
Out of curiosity: why? :-)=C2=A0

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

HTH=C2=A0
Michael=C2=A0
PS: make sure to keep the list i= ncluded, this about the extent of what I can add here!=C2=A0


# 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=C2=A0 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?=C2=A0 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--