strange hanging behaviour

strange hanging behaviour

[Andrew Gallagher]

Hi there,

I have been using zsh version 3.0.5 for a long time and it has never
given me trouble until now. On one particular Linux (Red Hat 5.0, 2.0.36
kernel) machine it has started to exhibit strange behaviour for no
immediately apparent reason. When my .zlogin asks me what terminal I am
using it accepts input properly, but once at the prompt I can only type
one or two characters before the shell input hangs. If I hit return
_twice_ then the shell gloops up the character buffer, does what I typed
and continues, but then hangs once again when I start typing the next
command.
This behaviour only happens in zsh - if I run ksh or tcsh (but not
another zsh) from within my misbehaving zsh, everything works fine, only
to break again once I exit and get back out into zsh. I have removed all
my dotfiles to no avail. The system config files are distribution. Login
method (telnet, ssh, etc.) makes no difference.

Anyone got any ideas? By the way, this all started on the day of the
eclipse. Spooky eh?

--
Andrew Gallagher
Dept. of Applied Maths
Queen's University of Belfast
http://members.tripod.com/~AndrewGallagher/id.html

Re: strange hanging behaviour

[Bart Schaefer]

On Aug 16,  9:24pm, Andrew Gallagher wrote:
> Subject: strange hanging behaviour
> 
> Anyone got any ideas?

What's the machine's uptime ?  There's a bug in ths system select() call
that kicks in after about 248 days, if I recall correctly.

That bug is fixed in 3.0.6, you might consider upgrading.

Re: strange hanging behaviour

[Andrew Gallagher]

Bart Schaefer wrote:

> On Aug 16,  9:24pm, Andrew Gallagher wrote:
> > Subject: strange hanging behaviour
> >
> > Anyone got any ideas?
>
> What's the machine's uptime ?  There's a bug in ths system select() call
> that kicks in after about 248 days, if I recall correctly.
>
> That bug is fixed in 3.0.6, you might consider upgrading.

Well, I did upgrade, and it fixed the problem (thanks!), but it caused me a
little bit of bother on the way. The ./configure script didn't find the
function yp_all properly. It turns out that this is because it doesn't
actually _look_ for yp_all - it looks for getdomainname and assumes yp_all
is available once getdomainname is found. Unfortunately (for whatever
reason) on my system getdomainname is found easily but yp_all has to be got
from libnsl. I fixed the problem by hacking configure.in to insert an
explicit search for yp_all (by simply changing instances of getdomainname
to yp_all) et voila. Is this just my server's fault (which I could easily
believe!) or does RH Linux do this to other people?


--
Andrew Gallagher
Dept. of Applied Maths
Queen's University of Belfast
http://members.tripod.com/~AndrewGallagher/id.html

Re: strange hanging behaviour

[Bart Schaefer]

On Aug 30, 10:37pm, Andrew Gallagher wrote:
} Subject: Re: strange hanging behaviour
}
} The [3.0.6] ./configure script didn't find the function yp_all
} properly. It turns out that this is because it doesn't actually
} _look_ for yp_all - it looks for getdomainname and assumes yp_all is
} available once getdomainname is found. Unfortunately (for whatever
} reason) on my system getdomainname is found easily but yp_all has to
} be got from libnsl.

Aha.  That would explain one of the patches I found in RedHat's .src.rpm
for zsh 3.0.5; their patch simply brute-forced linkage with -lnsl, for no
reason PWS or I could fathom.  I don't run NIS on any of my linux boxes,
so I've never noticed the lack of yp.

yp_all is only used if HAVE_NIS is defined and HAVE_NIS_PLUS is not; but
configure.in is not organized to discover NIS until long after it has
tested for most library linkages, so I think I'll just ask you to try the
patch below and tell me how it goes.  If you don't have autoconf and
autoheader available, drop me a note and I'll send you the (biggish) diffs
for the configure script and config.h.in file.

The relevant fragment of output on my system is

....
checking for library containing getdomainname... none required
checking for library containing yp_all... -lnsl
....

} Is this just my server's fault (which I could easily believe!) or does
} RH Linux do this to other people?

I think it probably does it to everybody.

I'm not entirely happy with this patch, as it will link with -lnsl even
when HAVE_NIS is not defined -- configure.in ought to be reordered to see
whether zsh wants a particular function at all before trying to find out
what library it's in.


Index: configure.in
===================================================================
@@ -372,11 +372,9 @@
 done
 
 dnl Some systems (Solaris 2.x) require libnsl (Network Services Library)
-dnl to find getdomainname and yp_all
-AC_CHECK_FUNCS(getdomainname)
-if test $ac_cv_func_getdomainname = no; then
-  AC_CHECK_LIB(nsl, getdomainname)
-fi
+dnl to find getdomainname and yp_all; Linux requires it for yp_all only.
+AC_SEARCH_LIBS(getdomainname, nsl)
+AC_SEARCH_LIBS(yp_all, nsl)
 
 dnl I am told that told that unicos reqire these for nis_list
 if test `echo $host_os | sed 's/^\(unicos\).*/\1/'` = unicos; then

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

Re: strange hanging behaviour

[Andrew Gallagher]

Bart Schaefer wrote:

>  I don't run NIS on any of my linux boxes,
> so I've never noticed the lack of yp.
>

*grin* we have found that NIS under Red Hat raises other problems too... I
would recommend that you don't try to mix it with shadowed passwd files for a
start... (but that's going off topic)


> I think I'll just ask you to try the
> patch below and tell me how it goes.  If you don't have autoconf and
> autoheader available, drop me a note and I'll send you the (biggish) diffs
> for the configure script and config.h.in file.
>

Well, I've already got it fixed on this particular system, but there are
others around that I could try this patch on. I'll get back to you when I've
got round to it *80).


--
Andrew Gallagher
Dept. of Applied Maths
Queen's University of Belfast
http://members.tripod.com/~AndrewGallagher/id.html