Date: Sun, 19 Nov 2023 11:17:49 -0700 From: Warner Losh <imp@bsdimp.com> To: bob prohaska <fbsd@www.zefox.net> Cc: freebsd-current@freebsd.org Subject: Re: How much survives an install/reboot cycle? Message-ID: <CANCZdfqEAxBKsc%2B63gg9oX2Xcn6m%2BRr_uOPOr68rs7-tQzYF-Q@mail.gmail.com> In-Reply-To: <ZVou9u%2BXxrXCf0fJ@www.zefox.net> References: <ZVou9u%2BXxrXCf0fJ@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <fbsd@www.zefox.net> 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 <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 Sun, Nov 19, 2023 at 8:51=E2=80=AF= AM bob prohaska <<a href=3D"mailto:fbsd@www.zefox.net">fbsd@www.zefox.ne= t</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin= :0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"= >How much of a running system's state survives a reboot? I used to thin= k<br> the answer was "nothing", but from time to time a second reboot b= ehaves<br> a=C2=A0 little differently from the previous one. <br> <br> The most recent example was an update to bpf.c: Prior to the update an<br> armv7 system had been inclined to drop ssh connections left up for days.<br= > After updating and running a build/install cycle the behavior persisted,<br= > but since a second reboot with no intentional changes it has stopped.<br> <br> I've not tampered with nextboot, so I don't think that's it. Ma= ybe I'm<br> just imagining imagining things.... <br></blockquote><div><br></div><div>Ge= nerally, nothing survives reboot. Nothing in RAM that is. Everything</div><= div>on disk should survie. swap survives boot, but we ignore it unless</div= ><div>there's a core dump in there.=C2=A0 Dirty pages in the buffer cac= he will be</div><div>flushed to disk, unless the reboot is a crash.</div><d= iv><br></div><div>And sometimes, RAM will survive a reboot. It all depends = on what the BIOS</div><div>does. I've had dmesg survie several reboots = because the kernel was the same</div><div>and the msgbuf wound up in the sa= me place and we recovered (And appended to)</div><div>that (though saying t= hat now, I'm not sure how FreeBSD does that). Some machines</div><div>d= on't destructively memory test all RAM and/or clear RAM on a warm reboo= t.</div><div><br></div><div>ssh dropping connections, though, may be a feat= ure of ssh. Check that the</div><div>following options haven't change a= nd/or aren't causing you problems:</div><div>ServerAliveCountMax, Serve= rAliveInterval, or TCPKeepAlive (for the client) and</div><div>ChanelTimeou= t, UnusedConnectionTimeout, ClientAliveCountMax, ClientAliveInterval,</div>= <div>or TCPKeepAlive (for the server). I hit this with ForwardX11Timeout wh= ich</div><div>I had set to 99999w but now have to set it to 999w since sshd= rejected such</div><div>a long time. The default values of these change at= random (at least seemingly</div><div>so for people like me that can't = be bothered to read the release notes). I'm not</div><div>completely su= re this is your problem, but if it is weird, it may be.</div><div><br></div= ><div>Warner<br></div></div></div> --000000000000ee22fb060a8562f4--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfqEAxBKsc%2B63gg9oX2Xcn6m%2BRr_uOPOr68rs7-tQzYF-Q>