more about screen

[Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>]

Hello,

screen is an interesting program becuase it gives you several virtual
consoles on the Hurd.

Unfortunately, it still doesn't work right. But we are close!

If you want to help, please apply the following patch first, which is a
temporary hack:

--- ../screen-3.7.4/misc.c	Mon Jun 23 22:57:18 1997
+++ misc.c	Tue Jun  8 18:24:58 1999
@@ -276,6 +276,7 @@
 closeallfiles(except)
 int except;
 {
+#ifndef __GNU__ /* Make proper check here with sysconf */
   int f;
 #ifdef SVR4
   struct rlimit rl;
@@ -292,6 +293,7 @@
   while (--f > 2)
     if (f != except)
       close(f);
+#endif
 }
 
 /*


Please compile screen with -DDEBUG, it will create debug info in /tmp/debug/
(wow, how silly). If you now start screen, it will show you the help or
welcome splash screen and wait for a key. Pressing a key will return you to
your original shell, but the socket stays open (SIGHUP'ed). You can try to
reattach, but it won't work any better. Furthermore, the terminal won't echo
anymore (type "reset") and important control commands are now blocked (CTRL+C,
CTRL+Z), so you should log out and login again to fix that.

What has happened? The debug log shows the following:
/tmp/debug/SCREEN.1161   # 1161 is the pid I assume 

(lot's of good stuff)
(lots of messages that it tries OpenPty's)
OpenPTY tries '/dev/ptyeb'
OpenPTY tries '/dev/ptyec'
OpenPTY tries '/dev/ptyed'
OpenPTY tries '/dev/ptyee'
OpenPTY tries '/dev/ptyef'
OpenPTY tries '/dev/ptyp0'
NewWindowAcl root's umask_w_bits for window 0
AclCheckPermWin(root, 1, 0) = 0
ChangeWindowSize from (0,0)+0 to(80,25)+100
fy -1 ty 124
forking...
MakeWindow will log in.
TtyNameSlot(/dev/ttyp0)
SetUtmp 0 will get slot 134799601...
rlogin hostname: ':console:S.0'
did freetty 4
SetUtmp successful
Activate(0)
ResizeDisplay: to (80,25).
ResizeDisplay: No change
Entering new layer  display 0x8087420  D_fore 0x808bea0  oldlay 0x808bebc
ASYNC: wrote 256 - remaining 770
ASYNC: wrote 256 - remaining 514
ASYNC: wrote 256 - remaining 258
ASYNC: wrote 256 - remaining 2
Read error: 1073741829 - SigHup()ing!          <==== HERE !!!!!!
SigHup()
Detach(0)
ResizeDisplay: to (80,25).
ResizeDisplay: No change
Flush(): 8
RemoveUtmp(ttyp0)
RemoveUtmp successfull
RestoreLoginSlot()
 logging you in again (slot console)
display: 0x8087420 displays: 0x8087420
did freetty -1
Detach: Signal 1 to Attacher(1160)!
Detach returns, we are successfully detached.
FinitHandler called, sig 15.
Finit(1);
RemoveUtmp(no slot (0))
There is no utmp-slot to be removed(0)
ChangeWindowSize from (80,25)+100 to(0,0)+0
fy 124 ty -1
we unlink(/var/run/screens/S-root/1161.console.hurd)


I marked the failing message above with "<==== HERE !!!!".
Where does it come from, and what does it mean?

1073741829 is "Input/output error" = EIO

it comes from:
flora:/gnu/src/screen/screen-3.7.4.l# grep "Read error" *.c
screen.c:                 debug1("Read error: %d - SigHup()ing!\n", errno);


              buflen = read(D_userfd, buf, maxlen);
              if (buflen < 0)
                {
                  if (errno == EINTR)
                    continue;
#ifdef EAGAIN
                  /* IBM's select() doesn't always tell the truth */
                  if (errno == EAGAIN)
                    continue;
#endif
                  debug1("Read error: %d - SigHup()ing!\n", errno);
                  SigHup(SIGARG);
                  sleep(1);
                }
              else if (buflen == 0)


and so on. read() is not succesful on D_userfd. How was D_userfd obtained?

D_userfd is given as the fourth argument to MakeDisplay (see display.c),
which is "n" below.

  if (!detached)
    {
      /* reopen tty. must do this, because fd 0 may be RDONLY */
      if ((n = secopen(attach_tty, O_RDWR, 0)) < 0)
        Panic(0, "Cannot reopen '%s' - please check.", attach_tty);
    }
  else
    n = -1;

if (MakeDisplay(LoginName, attach_tty, attach_term, n, MasterPid, &attach_Mode) == 0)

secopen is defined in fileio.c and prints in debug file:
  debug3("secopen(%s, 0x%x, 0%03o)\n", name, flags, mode);

I can find this in my debug file:
secopen(/dev/console, 0x3, 0000)

So, userfd is a file descriptor on /dev/console, opened with 0x3. The debug
output and thesource code shows that it was opened succefully.

If anybody wants to work on this, he would have to find out why the read on
the file descriptor returns EIO. I am lost at this point. screen does a lot
of funny stuff with fd_sets, too, maybe this is related.

But this definitely looks better than with the old glibc.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org   finger brinkmd@ 
Marcus Brinkmann              GNU    http://www.gnu.org     master.debian.org
Marcus.Brinkmann@ruhr-uni-bochum.de                        for public  PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/       PGP Key ID 36E7CD09