1 Jan
2022
1 Jan
'22
2:36 a.m.
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
1 Jan
1 Jan
8:46 a.m.
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 <will.senn(a)gmail.com> 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
9:18 a.m.
Classically, files don't get de-allocated (their blocks re-added to the filesystem
free list) until the last open reference to their inode is removed, even if the file name
is removed from all directories.
This behavior is commonly used for temporary files: open(2) with O_CREAT and unlink(2),
and file disappears when the file descriptor is finally closed or the process exits
without explicitly closing the descriptor (the kernel will close all descriptors
associated with an exiting process).
Where process accounting is concerned, the kernel itself holds the inode reference until
it is explictly told to turn off process accounting. See acct(2).
Erik Fair
9:36 a.m.
It was bad luck if the process holding your file open was an unkillable
zombie. Reboot and clri fixes all things. Okay maybe "fix" isn't the word
I
want...
On Sat, 1 Jan 2022, 1:27 pm Erik E. Fair, <fair-tuhs(a)netbsd.org> wrote:
Classically, files don't get de-allocated (their
blocks re-added to the
filesystem free list) until the last open reference to their inode is
removed, even if the file name is removed from all directories.
This behavior is commonly used for temporary files: open(2) with O_CREAT
and unlink(2), and file disappears when the file descriptor is finally
closed or the process exits without explicitly closing the descriptor (the
kernel will close all descriptors associated with an exiting process).
Where process accounting is concerned, the kernel itself holds the inode
reference until it is explictly told to turn off process accounting. See
acct(2).
Erik Fair
1085
days inactive
1086
days old
3 comments
4 participants
participants (4)
-
Erik E. Fair -
George Michaelson -
Jacob Ritorto -
Will Senn