Re: Terminal problem with linux-2.0.34

Re: Terminal problem with linux-2.0.34

[Ville Herva]

First off, I just noticed that although the problem appears with 3.1.5 and
zsh-3.1.5-pws-8, it is a bit different (better) compared to 3.0.5: 
everything I type gets echoed just fine, but pressing backspace works only
once, after that, the edits won't be echoed. Also moving on the command
line with arrow keys loses the cursor. To execute the command line, two
returns are needed. 

> Peter Stephenson <pws@ibmth.df.unipi.it> wrote:
>
> "Larry P . Schrof" wrote:
>
> > - Any time the user runs a program that makes a stat() call, the
> > shell hangs forever, until the user breaks out of it. Even after sending
> > the process, say ls -l, a signal, it takes awhile to get the shell prompt
> > back.
>
>Something this weird suggests zsh is tickling something in Linux, and
>also
>suggests the only way to find out what is just painfully to comment bits
>of
>code out until it goes away; it's probably not just zle.  (Does the
>stat()
>problem go away if you run zsh without zle?)

Today, I came across a very interesting problem with tha same linux
machine: the clock() function would always return -1! A little
sample prog:

vherva@turing:/home/vherva/zsh-3.1.5-pws-8/Src>cat ../../c.c
#include <time.h>
#include <stdio.h>

int main(int argc, char* argv[]) 
{
   int i;
   int timer = clock();
   for (i = 1000000; i; i--);  
   printf("timer: %i\nclock(): %i\nCLK_TCK: %i\n"
          "CLOCKS_PER_SEC: %i\n%3.2f 3.2f secs.\n", 
          timer, clock(), CLK_TCK, CLOCKS_PER_SEC,
          (float)(clock() - timer) / (float)CLK_TCK / 10000.0,
          (float)(clock() - timer) / (float)CLOCKS_PER_SEC);

   return 1;
}
vherva@turing:/home/vherva/zsh-3.1.5-pws-8/Src>gcc ../../c.c -o ../../c
vherva@turing:/home/vherva/zsh-3.1.5-pws-8/Src>../../c
timer: -1
clock(): -1
CLK_TCK: 100
CLOCKS_PER_SEC: 1000000
0.00 3.2f secs.

Now, making little heuristic guess I figured that

vherva@turing:/home/vherva/zsh-3.1.5-pws-8/Src>perl -e '$CLK_TCK = 100;
print 2**31 / $CLK_TCK / 60 / 60 / 24, " days\n"'
248.551348148148 days

which is quite accurately the uptime, zsh became not to work.

This, of course won't explain why zsh messes the command line, while other
shells do not. Is clock() or any similar function used in zle? (There is a
possibility that other timing functions fail, also - it seems that a
counter in the kernel has wrapped around, and libc goes nuts, or something
like that.)

Also, this might explain the other problems Larry Schrof had.

I'll be forwarding this problem to linux-kernel list.

>Also, it would be worth making sure it isn't in the latest development
>version
>http://www.ifh.de/~pws/computing/zsh-3.1.5-pws-8.tar.gz
>since the stuff that opens the terminal has changed a bit.

Zsh-3.1.5-pws-8 seems to behave exactly like zsh-3.1.5.
 

-- v --

v@iki.fi

Re: Terminal problem with linux-2.0.34

[Thomas Köhler]

Larry P . Schrof <schrof@cig.mot.com> wrote:

> > zsh-3.1.[245] (didn't test other versions). If I start zsh from within
> > screen, everything is OK... Strange problem with terminal emulation? I
> > don't know... I tried $TERM={xterm, vt300, linux}, nothing worked...
> > I tried with "setopt zle" and with "unsetopt zle", always the same
> > problem... what's going on here?
> 
> Remember - the problem seems to be very correlated to how deep your
> zsh shell is - SHLVL. (If indeed this is the same problem)

Seems to be a different problem... if I don't run screen, the problem is
there no matter how deep SHLVL is (I tried up to 4), wheras in screen,
the problem isn't there...

> If you're firing up screen first and then running zsh, SHLVL will be
> one higher than normal. Out of curiosity, what is the uptime on that
> box?

The problem is there on several linux boxes - uptimes:

janix~> uptime
 10:02am  up 13 days, 17:15,  9 users,  load average: 2.12, 2.10, 2.12
picard~> uptime
 10:03am  up 1 day, 15:30,  5 users,  load average: 0.29, 0.22, 0.08
willkuere~> uptime
 10:05am  up 187 days, 16:09h,  5 users,  load average: 0.00, 0.00, 0.00

Seems to be a problem with zsh and dxterm (aka DEC term).

> - Larry

CU,
Thomas

-- 
    Thomas Köhler    Email:     jean-luc@picard.franken.de
        <><           WWW:    http://home.pages.de/~jeanluc/
                      IRC:               jeanluc
      LCARS --- Linux for Computers on All Real Starships

Re: Terminal problem with linux-2.0.34

[Larry P . Schrof]

> zsh-3.1.[245] (didn't test other versions). If I start zsh from within
> screen, everything is OK... Strange problem with terminal emulation? I
> don't know... I tried $TERM={xterm, vt300, linux}, nothing worked...
> I tried with "setopt zle" and with "unsetopt zle", always the same
> problem... what's going on here?

Remember - the problem seems to be very correlated to how deep your
zsh shell is - SHLVL. (If indeed this is the same problem)

If you're firing up screen first and then running zsh, SHLVL will be
one higher than normal. Out of curiosity, what is the uptime on that
box?

- Larry

Re: Terminal problem with linux-2.0.34

[Thomas Köhler]

Larry P . Schrof <schrof@cig.mot.com> wrote:

[problems with Linux / remote logins]

Another strange problem occurs here:
If I run a DEC term (a replacement for xterm for DEC Unix) and then
rlogin/telnet/ssh to a linux box, my zsh won't work as expected:
Whenever I hit "cd somedir", zsh hangs and nothing helps - even killing
the shell won't give me the terminal back. This happens with
zsh-3.1.[245] (didn't test other versions). If I start zsh from within
screen, everything is OK... Strange problem with terminal emulation? I
don't know... I tried $TERM={xterm, vt300, linux}, nothing worked...
I tried with "setopt zle" and with "unsetopt zle", always the same
problem... what's going on here?

-- 
    Thomas Köhler    Email:     jean-luc@picard.franken.de
        <><           WWW:    http://home.pages.de/~jeanluc/
                      IRC:               jeanluc
      LCARS --- Linux for Computers on All Real Starships

Re: Terminal problem with linux-2.0.34

[Larry P . Schrof]

This is amazing. I never thought anyone else would actually be having
this problem. I also have a machine running 2.0.34, and it has a lot
of uptime. You describe it perfectly, but I have additional
symptoms:

- Any time the user runs a program that makes a stat() call, the
shell hangs forever, until the user breaks out of it. Even after sending
the process, say ls -l, a signal, it takes awhile to get the shell prompt
back.

At first, this problem would go away simply by running another zsh
and thus incrementing SHLVL. Another solution was to ssh in, run an xterm
that then ran zsh - this put me one shell level deeper as well, which
fixed the problem.

However, after a fwew more months of uptime, the bug would KICK ME OFF the
system when I tried to log in. I ssh'ed in and ran an xterm, which
spawned zsh. So now, I was a shell level deeper, which USED to fix
the problem. Instead, it exhibited the behavior that we described above -
no echoing of characters, hitting return twice (honestly, it sounds like
a lag behind by a certain # of keystrokes problem), etc. etc.

Once the behaviort got the state describe in the last paragraph, zsh
would also unexpectedly seg fault when running certain processes.
(I could not correlate a pattern as to which ones bailed and which ones
didn't)

My guess is that it's either zsh or something with Linux.  To those of
you who have not seen this problem, it is NASTY. It makes interactive
sessions nearly impossible.

- Larry

On Sun, Feb 14, 1999 at 11:26:53AM +0200, vherva@turing.netspan.fi wrote:
> I have been using zsh on a linux-2.0.34 machine without any problems.
> However, when the uptime exceeded 250 days, the zsh began having problems
> with the terminal. Of course, the uptime should have nothing to do with
> this, but on the other hand, there where no software updates that I could 
> imagine having affect to zsh's terminal handling. Zsh, termcap, libc or 
> anything like that was not updated.
> 
> The flaw in the terminal handling appears as follows: when I type text
> on the command line, only the first two characters are echoed. The line
> does show up, if erase a character. Also, the command line is only
> executed after I press return twice.
> 
> I tried updating to 3.0.7 and 3.1.5, and the bug still appeared.
> 
> Needless to say, bash and other shell and tools are unaffected.
> 
> I have not experienced this problem on any other machine. Since the 
> problem only appeared after 250 days of uptime its rather hard to trace 
> down on other machines. However, I would appreciate any clues on where 
> to look. For now, I forced to use bash -- which is clearly not satisfactory 
> -- so I am keen to find fix or workaround for this.
> 
> 
>  
> -- v --
> 
> --
> Ville Herva   Ville.Herva@netspan.fi   +358-50-5164500
> Netspan Oy    netspan@netspan.fi       PL 65  FIN-02151 Espoo    
>               http://www.netspan.fi
> For my PGP key, finger vherva@netspan.fi.

Re: Terminal problem with linux-2.0.34

[Ville Herva]

On Sun, Feb 14, 1999 at 03:59:28PM -0800, you [Bart Schaefer] claimed:
> } The problem appears as before.
> 
> The only thing I can think of to suggest at this point is that you run
> "strace -v zsh +Z" and then examine what's output immediately following
> a "setopt zle" command.  I get, among other irrelevant things,
> 
> ioctl(10, SNDCTL_TMR_STOP, {c_iflags=0x540, c_oflags=0x5, c_cflags=0xbf,
> c_lflags=0x8a31, c_line=0, c_cc[VMIN]=1, c_cc[VTIME]=0,
> c_cc="\x03\x00\x08\x15\x04\x00\x01\x00\x11\x13\x00\x00\x12\x00\x17\x00
>       \x00\x00\x73"})
>  = 0

I got 

read(0, "setopt zle\n", 4096)           = 11
time(NULL)                              = 919056503
sigprocmask(SIG_BLOCK, [CHLD], [])      = 0
sigprocmask(SIG_BLOCK, [CHLD], [CHLD])  = 0
sigprocmask(SIG_UNBLOCK, [CHLD], [CHLD]) = 0
sigprocmask(SIG_UNBLOCK, [CHLD], [])    = 0
fstat(0, {st_dev=makedev(8, 3), st_ino=328182,
st_mode=S_ISVTX|0405, st_nlink=0,
 st_uid=4096, st_gid=0, st_blksize=919056412, st_blocks=0,
st_size=0, st_atime=0
, st_mtime=35/12/23-12:03:32, st_ctime=70/01/01-02:00:03}) = 0
fcntl(0, F_GETFL)                       = 0x2 (flags O_RDWR)
time(NULL)                              = 919056503
time(NULL)                              = 919056503
time(NULL)                              = 919056503
ioctl(10, TIOCSPGRP, [30250])           = 0
sigaction(SIGINT, {0x8071c80, [], 0}, NULL) = 0
sigaction(SIGINT, {0x8071c80, [], 0}, NULL) = 0
ioctl(10, TIOCSPGRP, [30250])           = 0
ioctl(10, SNDCTL_TMR_STOP, {c_iflags=0x540, c_oflags=0x5, c_cflags=0xbf,
c_lflag s=0x8a31, c_line=0, c_cc[VMIN]=1, c_cc[VTIME]=0,
c_cc="\x03\x00\x7f\x15\x04\x00\x01\x00\x11\x13\x00\x00\x12\x00\x17\x00
      \x00\x00\x73\xa0\xf9\xff\xbf\xb9\x87\x07\x08\x0a\x00\x00\x00\x01"}) = 0

> } That's what I would like to know, too...
> 
> I meant other users of that same machine, though anyone anywhere that is
> also having the problem would be good to hear from.

I seem to do a good job misunderstanding you all the time. The other users
of the machine tend to prefer bash (I have a hard time trying to
convinence them about zsh's superioty now that it does not work.) I have
used it as an ordinary user and as root - the problem shows the same way
as root, also. As I noted before I have also tried to disable my .zshrc,
but that had no effect. 


--
Ville Herva       Ville.Herva@netspan.fi   +358-50-5164500
Netspan Oy        netspan@netspan.fi       PL 65  FIN-02151 Espoo
PGP key available: http://www.iki.fi/v/pgp.html

Re: Terminal problem with linux-2.0.34

[Bart Schaefer]

On Feb 14, 11:48pm, Ville Herva wrote:
} Subject: Re: Terminal problem with linux-2.0.34
}
} If I use xterm or rxvt, I do so using the ssh's X forwarding capability
}  
} I have also logged in with ssh from a xterm running on the client side.
} 
} Using any of these method, the problem appear similarly.
} 
} > If you start several login sessions at a time, does it affect all of them?
} 
} Yes.

Well, that rules out all the common system-level tty-setup problems I'm
aware of.

} > } > What happens if you "unsetopt zle" or run zsh as "zsh +Z"?
} > } 
} > } Everything works as expected, the problem does not appear.
} > 
} > OK, then it's most likely an stty problem of some kind.  What happens if
} > you first start "zsh +Z" and then do "setopt zle"?
} 
} The problem appears as before.

The only thing I can think of to suggest at this point is that you run
"strace -v zsh +Z" and then examine what's output immediately following
a "setopt zle" command.  I get, among other irrelevant things,

ioctl(10, SNDCTL_TMR_STOP, {c_iflags=0x540, c_oflags=0x5, c_cflags=0xbf,
c_lflags=0x8a31, c_line=0, c_cc[VMIN]=1, c_cc[VTIME]=0,
c_cc="\x03\x00\x08\x15\x04\x00\x01\x00\x11\x13\x00\x00\x12\x00\x17\x00\x00\x00\x73"})
 = 0

} > Incidentally, are any other users having the same problem with zsh?
} 
} That's what I would like to know, too...

I meant other users of that same machine, though anyone anywhere that is
also having the problem would be good to hear from.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: Terminal problem with linux-2.0.34

[Ville Herva]

On Sun, Feb 14, 1999 at 09:46:36AM -0800, you [Bart Schaefer] claimed:
> On Feb 14,  3:50pm, Ville Herva wrote:
> } Subject: Re: Terminal problem with linux-2.0.34
> }
> } I'm afraid I do not have access to the console as the machine the bug
> } appears on is a server residing elsewhere.
> 
> OK, that's useful information.
> 
> Do you log in to the compute server and run xterm there with the display
> pointing back to your local X server, or do you start your xterm on the
> local machine and then rlogin?

If I use xterm or rxvt, I do so using the ssh's X forwarding capability
(ssh creates a proxy server on the server side and forwards the connection
through a crypted channel to the client's X server.)
 
I have also logged in with ssh from a xterm running on the client side.

Using any of these method, the problem appear similarly.

> Are you always using ssh?

For security reasons, that is the only way to connect the server.

> If you start several login sessions at a time, does it affect all of them?

Yes.

> } > What happens if you "unsetopt zle" or run zsh as "zsh +Z"?
> } 
> } Everything works as expected, the problem does not appear.
> 
> OK, then it's most likely an stty problem of some kind.  What happens if
> you first start "zsh +Z" and then do "setopt zle"?

The problem appears as before.

> } > If running X11, have you completely shut down and restarted the server?
> } 
> } No. This is something I just can't do since it is a production server.
> 
> I meant the X server process, not the compute server machine, but if you're

My mistake, that's clear when you read that sentence more carefully.

> only doing remote login and from several different places, the question
> doesn't apply.

I guess so.

> You are able to install a new zsh on the compute server, though?  So you
> have some adminstrator privileges for it?  If not, by what method are you
> starting zsh when you log in?

I have administrative privileges, and I've tried starting zsh straight
from /bin/zsh as part of the login process. I also tried executing the
newly compiled binary straight from the temporary directory.

I would also like to add that I tried removing my .zshrc, but the problem
still persisted. (I use the exact same .zshrc elsewhere, so I did not
imagine that to be the problem.)

> Incidentally, are any other users having the same problem with zsh?

That's what I would like to know, too...



--
Ville Herva       Ville.Herva@netspan.fi   +358-50-5164500
Netspan Oy        netspan@netspan.fi       PL 65  FIN-02151 Espoo
PGP key available: http://www.iki.fi/v/pgp.html

Re: Terminal problem with linux-2.0.34

[Bart Schaefer]

On Feb 14,  3:50pm, Ville Herva wrote:
} Subject: Re: Terminal problem with linux-2.0.34
}
} > } The flaw in the terminal handling appears as follows: when I type text
} > } on the command line, only the first two characters are echoed. The line
} > } does show up, if erase a character. Also, the command line is only
} > } executed after I press return twice.
} 
} I'm afraid I do not have access to the console as the machine the bug
} appears on is a server residing elsewhere.

OK, that's useful information.

Do you log in to the compute server and run xterm there with the display
pointing back to your local X server, or do you start your xterm on the
local machine and then rlogin?

Are you always using ssh?

If you start several login sessions at a time, does it affect all of them?

} > What happens if you "unsetopt zle" or run zsh as "zsh +Z"?
} 
} Everything works as expected, the problem does not appear.

OK, then it's most likely an stty problem of some kind.  What happens if
you first start "zsh +Z" and then do "setopt zle"?

} > If running X11, have you completely shut down and restarted the server?
} 
} No. This is something I just can't do since it is a production server.

I meant the X server process, not the compute server machine, but if you're
only doing remote login and from several different places, the question
doesn't apply.

You are able to install a new zsh on the compute server, though?  So you
have some adminstrator privileges for it?  If not, by what method are you
starting zsh when you log in?

Incidentally, are any other users having the same problem with zsh?

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: Terminal problem with linux-2.0.34

[Ville Herva]

On Sun, Feb 14, 1999 at 05:15:33AM -0800, you [Bart Schaefer] claimed:
> On Feb 14, 11:26am, vherva@turing.netspan.fi wrote:
> } Subject: Terminal problem with linux-2.0.34
> }
> } The flaw in the terminal handling appears as follows: when I type text
> } on the command line, only the first two characters are echoed. The line
> } does show up, if erase a character. Also, the command line is only
> } executed after I press return twice.
> 
> Are you running this under X or on the console?  If X, try the console.

I'm afraid I do not have access to the console as the machine the bug
appears on is a server residing elsewhere.

> Does it affect all the virtual terminals?  Does it affect remote logins?

I can only experiment with remote logins, and this happens under xterm,
rxvt and ssh with TERM=xterm, xterm-color, vt100 or everything I've tried.

> If you run "ps t$TTY:t", do any other processes show up as attached to
> the same terminal?

vherva@turing:/home/vherva>ps exa t$TTY:t
  PID TTY STAT  TIME COMMAND
23594  p7 S    0:00 -zsh HOME=/home/vherva USER=vherva LOGNAME=vherva PATH=/us
23706  p7 R    0:00 ps exa tttyp7 HOME=/home/vherva USER=vherva LOGNAME=vherva

> What happens if you "unsetopt zle" or run zsh as "zsh +Z"?

Everything works as expected, the problem does not appear.

> } I tried updating to 3.0.7 and 3.1.5, and the bug still appeared.
> 
> So that means you've logged out and back in and the problem still occurs?

Yes, this has been going on for about a month now. It happens during every
login session. Also, this it not limited to any machine or terminal
program from which I have logged in the server.

> If running X11, have you completely shut down and restarted the server?

No. This is something I just can't do since it is a production server.

> BTW, where did you get this so-called 3.0.7, and what were you running
> before you upgraded to it?  There's been no release in the 3.0 series
> since 3.0.5.

Sorry, my mistake. Should have been zsh-3.0.5-7.i386.rpm from
rawhide.redhat.com, before which I also tried zsh-3.0.5-6.i386.rpm from
ftp.redhat.com. 3.1.5 was taken directly from the Danish zsh mirror and
compiled locally with gcc 2.7.2.3.

Thanks for the quick response!


--
Ville Herva       Ville.Herva@netspan.fi   +358-50-5164500
Netspan Oy        netspan@netspan.fi       PL 65  FIN-02151 Espoo
PGP key available: http://www.iki.fi/v/pgp.html

Re: Terminal problem with linux-2.0.34

[Bart Schaefer]

On Feb 14, 11:26am, vherva@turing.netspan.fi wrote:
} Subject: Terminal problem with linux-2.0.34
}
} The flaw in the terminal handling appears as follows: when I type text
} on the command line, only the first two characters are echoed. The line
} does show up, if erase a character. Also, the command line is only
} executed after I press return twice.

Are you running this under X or on the console?  If X, try the console.
Does it affect all the virtual terminals?  Does it affect remote logins?
If you run "ps t$TTY:t", do any other processes show up as attached to
the same terminal?

What happens if you "unsetopt zle" or run zsh as "zsh +Z"?

} I tried updating to 3.0.7 and 3.1.5, and the bug still appeared.

So that means you've logged out and back in and the problem still occurs?
If running X11, have you completely shut down and restarted the server?

BTW, where did you get this so-called 3.0.7, and what were you running
before you upgraded to it?  There's been no release in the 3.0 series
since 3.0.5.
-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

(Who is awake because some random home appliance is making a beeping sound
for a few seconds every 10-20 minutes, and he can't track it down.  Argh.)

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Terminal problem with linux-2.0.34

[vherva]

I have been using zsh on a linux-2.0.34 machine without any problems.
However, when the uptime exceeded 250 days, the zsh began having problems
with the terminal. Of course, the uptime should have nothing to do with
this, but on the other hand, there where no software updates that I could 
imagine having affect to zsh's terminal handling. Zsh, termcap, libc or 
anything like that was not updated.

The flaw in the terminal handling appears as follows: when I type text
on the command line, only the first two characters are echoed. The line
does show up, if erase a character. Also, the command line is only
executed after I press return twice.

I tried updating to 3.0.7 and 3.1.5, and the bug still appeared.

Needless to say, bash and other shell and tools are unaffected.

I have not experienced this problem on any other machine. Since the 
problem only appeared after 250 days of uptime its rather hard to trace 
down on other machines. However, I would appreciate any clues on where 
to look. For now, I forced to use bash -- which is clearly not satisfactory 
-- so I am keen to find fix or workaround for this.


 
-- v --

--
Ville Herva   Ville.Herva@netspan.fi   +358-50-5164500
Netspan Oy    netspan@netspan.fi       PL 65  FIN-02151 Espoo    
              http://www.netspan.fi
For my PGP key, finger vherva@netspan.fi.