Subject: screen/ getutline() (libc) bug?

From: [email-masked] (joost witteveen)
Date: Fri, 14 Jun 1996 23:41:26 +0200 (MET DST)

I'm running into a rather serious "screen" bug:
start screen, exit from it, and *nobody* can login to your mashine
anymore (at least not via telnet): telnet will say:

  You must exec login from the lowest level shell.

The problem is that I'm not sure the bug is in screen. It
appears that the login progaramme tries to see if the current
tty (ttyname()) is in use already with getutline().

Now, if I log in with a login binary installed with extra debugging,
I see that the ttyname login is using is corect, and unused.
At least, both "who" and "last -f /var/run/utmp" don't show the
ttyname as used.
But for some reason,  getutline(&ut) decides to report it in use,
and the login fails.

Now, I don't know exactly what getutline is supposed to do
(no "man getutline", didn't unpack libc), so maybe it's right, and
it's screen that leaves utmp in a corrupt state.

I guess i'll have to go back to an old screen version just before monday,
if I don't find it, but I would love to hear from other people, what
might be the problem. (I would also like to know how many people
affects this).

For the really interested: lost's of numbers.

libc5.2.18-8, screen-3.7.1-4, netbase 2.03-1, netstd 2.03-1.

Maybe somebody knows more about what utmp entries aught to look
like than I do. In this utmp file, the offending tty is ttypf,
while "who" and "last -f utmp" don't report anyone on ttypf.

Some more random data:
If I now start an xterm (that will see that ttypf isn't
in use), I can login again. So, a full session would be:

action         result

$screen        I can login, and who reports ttypf as in use by screen
$exit          You must exec login from the lowest level shell.
$xterm         can login again; the xterm is using ttypf

during the login, the "myut" struct returned in
  login.c:355     myut = getutline(&ut);
called with ut a structure with ut_line set to "ttypf",
reads:
  ut_type=7, ut_pid= 20427, ut_line="ttypf"
  ut_id=pf, ut_time=834784045, ut_user=""
  ut_pid()=20427, getpid()=23715
pid 20427 isn't in use.

It appears to be related to screen, I haven't seen it otherwise
(well, I have once seen it before, but I don't remember wether that
might have been screen-related too).

Also, I think it's rather strange nobody reported this before
(just like I didn't notice it before), whereas for me now, it
really reproduces very well.

-- 
joost witteveen
            [email-masked]
          [email-masked]
--
Use Debian Linux!

---

From: Guy Maor <[email-masked]>
Date: Fri, 14 Jun 1996 16:54:08 -0500 (CDT)

>   You must exec login from the lowest level shell.

What version of login are you using?  login 1.0-5 checks if the utmp
entry is stale before erroring out.  It will most likely fix this
problem.

Guy

---

From: [email-masked] (joost witteveen)
Date: Fri, 14 Jun 1996 23:57:45 +0200 (MET DST)

> entry is stale before erroring out.  It will most likely fix this

THANKS (really, alot, for the quick answer). So, now all I
have to do is make it depend on login 1.0-5.

The problem seems to be with the local mirrors, I still
have 1.0-4 over here.

It's 24:00 over here now, but at least I'll be able to go to sleep
without that (rather big) worry, just before 1.1.