screen/ getutline() (libc) bug?

[joost@rulcmc.leidenuniv.nl (joost witteveen)]

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.

begin 644 utmp
M`0```#1.``!^``````````````!^?@``2W&_,7)U;FQE=F5L````````````
M```````````````&````2$<``'1T>3$``````````#$```#_J<$Q3$]'24X`
M``````````````````````````````<```!G"P``='1Y<#``````````<#``
M`%+TOS%P971E<@```')U;&=M:2YL96ED96YU;FG49@!`!P```"D>``!T='EP
M,0````````!P,0``.73`,6IO;W-T````.C`N,````````````````-1F`$`'
M````RBL``'1T>7`R`````````'`R``"7*,$Q:F]O<W0````Z,"XP````````
M````````U&8`0`<```#A*P``='1Y<#,`````````<#,``%(IP3%J;V]S=```
M`#HP+C````````````````#49@!`!P```+DV``!T='EP-`````````!P-```
MAVO!,6IO;W-T````.C`N,````````````````-1F`$``````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````!P```"E%``!T='EP-P````````!P-P``2:+!,6IO;W-T````
M.C`N,````````````````-1F`$`'````UU4``'1T>7`X`````````'`X``#L
MT<$Q:F]O<W0````Z,"XP````````````````U&8`0`<```"[.```='1Y<#D`
M````````<#D```9TP3%J;V]S=````#HP+C````````````````#49@!`!P``
M`'Y#``!T='EP8@````````!P8@``CIG!,6IO;W-T````.C`N,```````````
M`````-1F`$`'````[T8``'1T>7!C`````````'!C``#MI\$Q:F]O<W0````Z
M,"XP````````````````U&8`0```````````````````````````````````
M````````````````````````````````````````````````````````````
M```````````````````````````````````````````````````````'````
MO4\``'1T>7!D`````````'!D``"XRL$Q:F]O<W0````Z,"XP````````````
M````U&8`0`<```#+3P``='1Y<&8`````````<&8``"W+P3$`````````````
M````````````````````````!P```$I.``!T='EQ,`````````!Q,```C[W!
M,6IO;W-T````.C`N,````````````````-1F`$`'````4$X``'1T>7$Q````
M`````'$Q``"4O<$Q:F]O<W0````Z,"XP````````````````U&8`0`<````A
M3P``='1Y<&4`````````<&4``+C$P3%J;V]S=````#HP+C``````````````
M``#49@!`"````*M/``!T='EQ,@````````!Q,@``F,K!,6IO;W-T````<G5L
18VUC+FQE:61E;G5N:83E`2$`
`
end


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
            joost@rulcmc.leidenuniv.nl
          joostje@debian.org
--
Use Debian Linux!