From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 31676 invoked from network); 1 Jan 2022 02:47:20 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 1 Jan 2022 02:47:20 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id B3D379D039; Sat, 1 Jan 2022 12:47:18 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 561209CF51; Sat, 1 Jan 2022 12:46:47 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="gTwhMngT"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 3C2659CF51; Sat, 1 Jan 2022 12:46:44 +1000 (AEST) Received: from mail-pg1-f177.google.com (mail-pg1-f177.google.com [209.85.215.177]) by minnie.tuhs.org (Postfix) with ESMTPS id EE7009CF06 for ; Sat, 1 Jan 2022 12:46:42 +1000 (AEST) Received: by mail-pg1-f177.google.com with SMTP id 200so25174222pgg.3 for ; Fri, 31 Dec 2021 18:46:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sRWHir73NrR91DRypT04wIE1U9/cpXaDy1Hhvaskg+U=; b=gTwhMngTMibB6Hw/IOU7tbs5ZAQlZ9E3D7YaccK0miWQooMab1L3hirK0lz0AGi5XS ZZVb20091zd5X4RBF/mu6PAmqGSBg+b+hDWlG7EGHPU2o9kFzITsEKaOihROfxFL0AVS PQsX5IifoOIuatGJnJz4dnsdOEQTcoTHjHJZ8kvOY48qtjvf7cusuMN87uRA/Q5T37EJ +CbJm/yZ6goGcrkSmxkOwAeVHjlN+/LGWDydc70JDjYr1p1DhbArOo3LEhY0pbDqHoDj Iv8u+Mfr+lZN/cn2vrKQpVaeOKtqAy/DCE1BpG/Cfy818i4cMKSWVLE6aP2LWpk9wP1s /1pA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sRWHir73NrR91DRypT04wIE1U9/cpXaDy1Hhvaskg+U=; b=wCUq/Wq4vJtWK6w5p/7F2GyaJV5QWJGVyKTJTLbUwRLax5gIyGY7NLbUo8EVTxqCN4 wwU45QNofXK737s5H/jELfv+egiUD0krm8DCp/kYEPqdtJ9huXSBrFR3ZW93pNZ49GZp deS/HXb+KfpZwQE+QzVAXWM3jwASONYcVcCjmx/XpcV/x+v3OKM3rBK2R8ONr+LGvZRB UrphP1fv4SZi4dyO62yhF1kIO53dspDsC20rfSPRtGwWY2cyXyXGf3V6QB3T3bYX4jTF /lgerXV87XxYllqsMhPqi6f5cMiOeOCoB9eETrCvguaZYVMZmK74ZlGsJo+/EHF2w6O4 AoQw== X-Gm-Message-State: AOAM530/yQUMrFHO+lFIJ4IlyxB438sS9tLn3g+hsNzBrU3BD4ha04PZ MapJJ7tdWEq79qxzN/9SH2Q9ydu0hnbwLkeXcNw2UEQw X-Google-Smtp-Source: ABdhPJzMfa4M2hTAPLZwej0oz4MZlGXrqdWiyMDPMRssHjXmBb80F4R/Du6q3QCqT56hhuZkMzmCM89vrruvoT7V4/k= X-Received: by 2002:a05:6a00:1249:b0:4bb:4a31:1e0a with SMTP id u9-20020a056a00124900b004bb4a311e0amr37699135pfi.81.1641005202310; Fri, 31 Dec 2021 18:46:42 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Jacob Ritorto Date: Fri, 31 Dec 2021 21:46:05 -0500 Message-ID: To: Will Senn Content-Type: multipart/alternative; boundary="0000000000002888d305d47c4cc5" Subject: Re: [TUHS] v7 /etc/ttys and /usr/adm/wtmp shenanigans X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: tuhs main list Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --0000000000002888d305d47c4cc5 Content-Type: text/plain; charset="UTF-8" My boss 23 years ago (who was at CMU in the eighties working on systems like these) told me that on some systems, when cleaning up wtmp, it's necessary to truncate the wtmp file (i.e. cat /dev/null into it -- never to flat out remove it) because something in the system doesn't let go of the inode (or somesuch) that it thinks the file was on. I never understood why but have done what he told me since then :) I wonder if this has something to do with your phenomenon. On Fri, Dec 31, 2021 at 4:41 PM Will Senn wrote: > I enabled user accounting on my v7 instance and I noticed it "growing > without bound" and while this is noted as a possibility in the ac(1) man > page, I was pretty sure the original authors didn't mean 30k a second. I > scratched my head and thought for a while and then started experimenting to > see what the heck was going on. I removed /usr/adm/wtmp (which I had > created to enable accounting in the first place) and the little red disk > write arrow on my mac went away, but not the little green disk read > arrow... hmm. Something was keeping my v7 instance very busy reading disk, > that was for sure. I went through a few (dozens) more tests and > experiments, reread a bunch of man pages, Ritchie's v7 install note, and > thought some more and here's what I came up with... > > If you modify your system to add dci lines and you enable some ttys in > /etc/ttys and you enable user accounting. Then, the next time you boot into > a kernel that doesn't have dci support, init or some other process will try > and fail to read the enabled ttys, log something in /usr/adm/wtmp, if it > exists, and then loop (very quickly), over and over and over. If you aren't > paying attention, this will hardly be noticeable on modern hardware running > simh, but I'm guessing this would have been disastrous, back in the day. > > The simple solution is to boot w/dci enabled when you have ttys enabled, > and only boot w/o dci enabled when you have disabled the ttys. > > I'm guessing that this wasn't really ever an issue, back in the day, as > folks prolly didn't just yank their dci's and reboot a different kernel? > But, such are the joys of simulation. > > Anyhow, if this doesn't sound like a very likely or reasonable analysis of > what was happening, I'd appreciate your letting me know, or if you've > experienced something like it before, it'd be great to know that I'm not > alone in this silliness. > > Will > --0000000000002888d305d47c4cc5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
My boss 23 years ago (who was at CMU in the eighties worki= ng on systems like these) told me that on some systems, when cleaning up wt= mp, it's necessary to truncate the wtmp file (i.e. cat /dev/null into i= t -- never to flat out remove it) because something in the system doesn'= ;t let go of the inode (or somesuch) that it thinks the file was on.=C2=A0 = I never understood why but have done what he told me since then :) =C2=A0= =C2=A0

I wonder if this has something to do with y= our phenomenon.

On Fri, Dec 31, 2021 at 4:41 PM Will Senn <will.senn@gmail.com> wrote:
=20 =20 =20
I enabled user accounting on my v7 instance and I noticed it "growing without bound" = and while this is noted as a possibility in the ac(1) man page, I was pretty sure the original authors didn't mean 30k a second. I scratched my head and thought for a while and then started experimenting to see what the heck was going on. I removed /usr/adm/wtmp (which I had created to enable accounting in the first place) and the little red disk write arrow on my mac went away, but not the little green disk read arrow... hmm. Something was keeping my v7 instance very busy reading disk, that was for sure. I went through a few (dozens) more tests and experiments, reread a bunch of man pages, Ritchie's v7 install note, and thought some more and here's what I came up with...

If you modify your system to add dci lines and you enable some ttys in /etc/ttys and you enable user accounting. Then, the next time you boot into a kernel that doesn't have dci support, init o= r some other process will try and fail to read the enabled ttys, log something in /usr/adm/wtmp, if it exists, and then loop (very quickly), over and over and over. If you aren't paying attention, this will hardly be noticeable on modern hardware running simh, but I'm guessing this would have been disastrous, back in the day= .

The simple solution is to boot w/dci enabled when you have ttys enabled, and only boot w/o dci enabled when you have disabled the ttys.

I'm guessing that this wasn't really ever an issue, back in t= he day, as folks prolly didn't just yank their dci's and reboot = a different kernel? But, such are the joys of simulation.

Anyhow, if this doesn't sound like a very likely or reasonable analysis of what was happening, I'd appreciate your letting me know, or if you've experienced something like it before, it'd= be great to know that I'm not alone in this silliness.

Will
--0000000000002888d305d47c4cc5--