The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Will Senn <will.senn@gmail.com>
To: tuhs main list <tuhs@minnie.tuhs.org>
Subject: [TUHS] v7 /etc/ttys and /usr/adm/wtmp shenanigans
Date: Fri, 31 Dec 2021 14:36:40 -0600	[thread overview]
Message-ID: <be45b84e-3853-2679-768b-1f995bdbb396@gmail.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 1881 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 2303 bytes --]

             reply	other threads:[~2021-12-31 21:41 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-31 20:36 Will Senn [this message]
2022-01-01  2:46 ` Jacob Ritorto
2022-01-01  3:18   ` Erik E. Fair
2022-01-01  3:36     ` George Michaelson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=be45b84e-3853-2679-768b-1f995bdbb396@gmail.com \
    --to=will.senn@gmail.com \
    --cc=tuhs@minnie.tuhs.org \
    --subject='Re: [TUHS] v7 /etc/ttys and /usr/adm/wtmp shenanigans' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).