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=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 25632 invoked from network); 31 Dec 2021 21:41:19 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 31 Dec 2021 21:41:19 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 850DA9D04C; Sat, 1 Jan 2022 07:41:14 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 4BF3D9CF06; Sat, 1 Jan 2022 07:40:45 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="ezV3WrRZ"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id CF52B9CF51; Sat, 1 Jan 2022 06:36:42 +1000 (AEST) Received: from mail-oo1-f53.google.com (mail-oo1-f53.google.com [209.85.161.53]) by minnie.tuhs.org (Postfix) with ESMTPS id 526F79CF06 for ; Sat, 1 Jan 2022 06:36:42 +1000 (AEST) Received: by mail-oo1-f53.google.com with SMTP id t13-20020a4a760d000000b002dab4d502dfso8684580ooc.6 for ; Fri, 31 Dec 2021 12:36:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:content-language:from :subject:to; bh=bpiGrL9KOmEJvr2x+Lij/ImGINJS4/DK5VNTbqyEq6A=; b=ezV3WrRZjCeaD3Tvcxoz5VotGtyRdQGKC88O6Chl+Qvqq/CVoZW1xOTW2Nbuyjl4zK wIP5uJi9liVeyaMzMgcD8QAMjXz6GaNPfmW8GmPK0aePFkms3cvDIU0BQmAdV7gSdlWv qFYEaOAJvxNwzUaZO/bSs6o7gv+iKonmMOyR1Rvsm59GjkncJbTYDIV/GIqfa4YwvLcF 9RwWH6zx0fTVIAnSdtTbFSnb2B08lq8kNcgyaHdhPS3D6gfyAPv7XmVAbRfMyerDTIOV 04mnX271rw9C25yrDdm7WyNtz89Upocb1/KEMr307Q8X+/H2uY2N5LqTXLsllPq6CZDH ig/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:from:subject:to; bh=bpiGrL9KOmEJvr2x+Lij/ImGINJS4/DK5VNTbqyEq6A=; b=AnUwseAmgMz7yFIYE4fFkrs+4isPO3PHN2K9QqI681hA8bbjNZ/fhgdLfoQLM9ybQ9 3w73Q3AZAepGAinrsmkxVm/UOzn/eghUzwMu4tCkPl/NZQZQQbsq8j3nn6L3atCMOnxy 8rAkY4ZbAa8R9AeVI8dpvy+QzEKdZm/oe9HUv24c2XvPgm5dlZEWNLtOdT4VRkkPAfme MYSTt9tHZHW2klwlRrJBKcs+q3ieZcaf4MXBdy933wEBR/jTVtr/SwTKiHbUINad5rst IULw2uQvOTQEFPV+mOysTHTJSnu+IfWY1uXJXUXRqpFLh1fVuZBmC3heCe2U0vlohkOo 3RPw== X-Gm-Message-State: AOAM531hohZ0uk2AnbJvFr/TOuaxJ9SOGCa77asBH17U89I4yPcyb2J7 yqgblMA5KqAxIbIFGTFk08abv4wcGUDfMQ== X-Google-Smtp-Source: ABdhPJyVFLvsdJ+X+HN3PzZ8t5IUZG9mlSRj+FHZyIv6JhYchBByj9zkIshuWjO+41C3ZpadlU9MLQ== X-Received: by 2002:a4a:ae46:: with SMTP id a6mr22883117oon.50.1640983001129; Fri, 31 Dec 2021 12:36:41 -0800 (PST) Received: from [10.8.3.4] ([2.56.190.92]) by smtp.gmail.com with ESMTPSA id c29sm5745091otd.14.2021.12.31.12.36.40 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 31 Dec 2021 12:36:40 -0800 (PST) Content-Type: multipart/alternative; boundary="------------ezsWQg0xVkxILp4S3ZQpw0r0" Message-ID: Date: Fri, 31 Dec 2021 14:36:40 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Content-Language: en-US From: Will Senn To: tuhs main list Subject: [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: , Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" This is a multi-part message in MIME format. --------------ezsWQg0xVkxILp4S3ZQpw0r0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 --------------ezsWQg0xVkxILp4S3ZQpw0r0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit 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
 --------------ezsWQg0xVkxILp4S3ZQpw0r0--