From nobody Sun Nov 19 18:17:49 2023 X-Original-To: freebsd-current@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 4SYJlc3QLhz517yG for ; Sun, 19 Nov 2023 18:17:48 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (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 4SYJlc1j6Vz4Q7W for ; Sun, 19 Nov 2023 18:17:48 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x536.google.com with SMTP id 4fb4d7f45d1cf-53e2308198eso5187580a12.1 for ; Sun, 19 Nov 2023 10:17:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1700417867; x=1701022667; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=i9ylEbd6rybsbbRPe5S+SZy2/rqKu766YiFlTf78Zvg=; b=W7pNml3SfVEQrsoFW+SbZDfR5ca0TJtgwD9AgSUSHgz5ZYAKtZ/c4qT6faqzcs8QGm b0WjDyayNC+08CsbKWpm/VoKpC+lO/xsdUAtZcscAw7vatH6d6JK+XiYjoRBStnxQ8wY bRaR3F4HIYr/pcQ+QaxT14tTO6YM+1MFlkAsKFUi7uvPXZkeZ1E5947Qlmam9x2qjPrc afC8cafXAzn5OLlr3kHPySVxEfYnzgHPlIA3rBApBaKv2k58yuzeP8DYGq23RnlPkTZi tZfsDzQGjTK8AELvGEVYFLWo6eaV6HkDvHOtoJ8Ra8W4eYkRifzH1dW1WDULIbRneGAT p1Xw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700417867; x=1701022667; 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=i9ylEbd6rybsbbRPe5S+SZy2/rqKu766YiFlTf78Zvg=; b=Vdu0UNLV8S1r6pPg0MrSjvYFmA6TIKwV0i9RWafceKGxaluWJWuZu0xMkI0+OwRJJm lffua1p/vPniPJNwNmMiyZ+rxEc+J/kANUK7vFMMF0MqALOtQFmO887Fy1iwxcL3tyvt COcURbpNcbbiXcGQZGfNiWy+JyrQzM+onhP8GcHhSzekg1AaJWCEIbBWF7w8KgaXmNQ/ 6EC+EoAkHBaSSLZY0mMHvUP3dtGVvgoWZXDbhCpVSh6e33paff/Kn2VL6/KbqusbgXTC 1gflhj5XSwyxYN0+uegWdjNFWBntQy+WpC14dT1wuuXa335yEaqyJ0oMudU5OyCQA0b3 dciQ== X-Gm-Message-State: AOJu0Yy75qFW2cRSfu8iuMuf3GSOjzt7KLk3Ztp3dPks5qDohi/TUZY9 oDbOXfxNCK6AkM6Xe0MqwMQAi97jW59u9bKDHDnf6fag2nX5qw9Tbhw= X-Google-Smtp-Source: AGHT+IFpt7gD8ReVYKkgTh6UbBtMXbGDf54gTsSEoEvn0OKSf38Kspt5XS54KbAhczEZyI/mhq8k31KyJCXWqQgkE+o= X-Received: by 2002:a05:6402:1a5a:b0:548:b096:6c0d with SMTP id bf26-20020a0564021a5a00b00548b0966c0dmr922142edb.38.1700417866959; Sun, 19 Nov 2023 10:17:46 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Sun, 19 Nov 2023 11:17:49 -0700 Message-ID: Subject: Re: How much survives an install/reboot cycle? To: bob prohaska Cc: freebsd-current@freebsd.org Content-Type: multipart/alternative; boundary="000000000000ee22fb060a8562f4" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4SYJlc1j6Vz4Q7W --000000000000ee22fb060a8562f4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Nov 19, 2023 at 8:51=E2=80=AFAM bob prohaska w= rote: > How much of a running system's state survives a reboot? I used to think > the answer was "nothing", but from time to time a second reboot behaves > a little differently from the previous one. > > The most recent example was an update to bpf.c: Prior to the update an > armv7 system had been inclined to drop ssh connections left up for days. > After updating and running a build/install cycle the behavior persisted, > but since a second reboot with no intentional changes it has stopped. > > I've not tampered with nextboot, so I don't think that's it. Maybe I'm > just imagining imagining things.... > Generally, nothing survives reboot. Nothing in RAM that is. Everything on disk should survie. swap survives boot, but we ignore it unless there's a core dump in there. Dirty pages in the buffer cache will be flushed to disk, unless the reboot is a crash. And sometimes, RAM will survive a reboot. It all depends on what the BIOS does. I've had dmesg survie several reboots because the kernel was the same and the msgbuf wound up in the same place and we recovered (And appended to= ) that (though saying that now, I'm not sure how FreeBSD does that). Some machines don't destructively memory test all RAM and/or clear RAM on a warm reboot. ssh dropping connections, though, may be a feature of ssh. Check that the following options haven't change and/or aren't causing you problems: ServerAliveCountMax, ServerAliveInterval, or TCPKeepAlive (for the client) and ChanelTimeout, UnusedConnectionTimeout, ClientAliveCountMax, ClientAliveInterval, or TCPKeepAlive (for the server). I hit this with ForwardX11Timeout which I had set to 99999w but now have to set it to 999w since sshd rejected such a long time. The default values of these change at random (at least seemingly so for people like me that can't be bothered to read the release notes). I'm not completely sure this is your problem, but if it is weird, it may be. Warner --000000000000ee22fb060a8562f4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Nov 19, 2023 at 8:51=E2=80=AF= AM bob prohaska <fbsd@www.zefox.ne= t> wrote:
How much of a running system's state survives a reboot? I used to thin= k
the answer was "nothing", but from time to time a second reboot b= ehaves
a=C2=A0 little differently from the previous one.

The most recent example was an update to bpf.c: Prior to the update an
armv7 system had been inclined to drop ssh connections left up for days. After updating and running a build/install cycle the behavior persisted, but since a second reboot with no intentional changes it has stopped.

I've not tampered with nextboot, so I don't think that's it. Ma= ybe I'm
just imagining imagining things....

Ge= nerally, nothing survives reboot. Nothing in RAM that is. Everything
<= div>on disk should survie. swap survives boot, but we ignore it unless
there's a core dump in there.=C2=A0 Dirty pages in the buffer cac= he will be
flushed to disk, unless the reboot is a crash.

And sometimes, RAM will survive a reboot. It all depends = on what the BIOS
does. I've had dmesg survie several reboots = because the kernel was the same
and the msgbuf wound up in the sa= me place and we recovered (And appended to)
that (though saying t= hat now, I'm not sure how FreeBSD does that). Some machines
d= on't destructively memory test all RAM and/or clear RAM on a warm reboo= t.

ssh dropping connections, though, may be a feat= ure of ssh. Check that the
following options haven't change a= nd/or aren't causing you problems:
ServerAliveCountMax, Serve= rAliveInterval, or TCPKeepAlive (for the client) and
ChanelTimeou= t, UnusedConnectionTimeout, ClientAliveCountMax, ClientAliveInterval,
=
or TCPKeepAlive (for the server). I hit this with ForwardX11Timeout wh= ich
I had set to 99999w but now have to set it to 999w since sshd= rejected such
a long time. The default values of these change at= random (at least seemingly
so for people like me that can't = be bothered to read the release notes). I'm not
completely su= re this is your problem, but if it is weird, it may be.

Warner
--000000000000ee22fb060a8562f4--