From: michael@gandalf.moria (Michael Haardt) Subject: 0.98.pl5, init, getty, login and deep despairation ... Date: Wed, 18 Nov 1992 01:04:44 +0100
Upgrading to 0.98.pl5 went fine, until I first booted the new kernel.
The result was wonderful, because init complained about all logins
respawning too fast. The reason was a core-dumping getty-2.03. So I
made entries for two shells in inittab and booted again.
After short debugging it was obvious that a quick hack in getty-2.03 was
the reason, it just never showed up. I removed the #ifndef linux, did
telinit q and at least I got my logins back. But now utmp entries
weren't removed when logging out. So I went through the chain init,
getty and login. Init makes utmp entries with id e.g. c4 for tty4. So
far so good. getty changed the id to 4, which it shouldn't do in my
opinion, otherwise there would be no reason for init to make id entries.
So I changed getty again. Then I had the idea to "get a production
version now where it runs". A bad idea, but I was able to do so after
adding a couple forgotten #ifdef DEBUGs. Not to talk about the fact,
that of course SETTERM wasn't set and TTYTYPE was set to "x" -- a mess.
Then login didn't care about existing entries at all and I had duplicate
entries, one with c4 and one with 4. ARGH! So I changed login to change
an existing entry if possible. And, to be sure, I changed init for only
looking for the pid instead of id when it returns from wait(), because
as we know, processes may not care about the id and change it.
The moral of the story? I don't know, can someone help me? Are there
really so many bugs, or did I just totally misunderstand it? I can't
believe that I have to send out cdiffs to three persons now ... I only
wanted to get a new kernel which doesn't have that page bug.
Linus, keep up the good work. Better to get the bad surprises with
applications now than later, and without a kernel which implements
readonly code pages now, I would never have found that wrong hack in
getty. I wonder which other software will die next time ...
... to be continued ;-)
Michael "seeing more bugs than bytes"