In message <m0sbOXq-00008hC@waux11.ahwau.ahold.nl>  Leo Weppelman wrote:
> 
> 
> I am having a rather curious problem. Sometimes when I issue a command
> like '<someting> | more' the more 'hangs'. It does not happen very
> often and I can not reproduce it ;-( Non of the usual signals from the
> keyboard will get it out [ intr/kill/susp ]. The only way is a kill -9
> on one of the other screens (if you're multi-user).
> 
> When I do a stacktrace from the debugger, I see something like:
> 
> issignal()  [ pstat == SSTOP !? ]
> tsleep()
> ttysleep()
> [....]
> ttioctl()   [ turned out to be SETAW ]
> [....]
> syscall()

My guess is you're using (pd)ksh. (maybe every shell with comandline editing
has the feature)
There is a race condition setting up the terminal state (with ttioctl) in a 
childprocess and setting the process group of the terminal from another child. 

One child gets a SIGTSTOP if tries to do the SETAW when the terminal doesn't
belong to it's processgroup. (and sometimes the 2'nd child is faster and you see
the hang. BTW. a SIGCONT should help here).

Best known fix, synchronise the parent shell with it child(s) through pipes
or socketpairs.
E.g. Wait for a child to gets it's termnial setting done before forking
another one or, block the 2'nd child until it can savely change tty onwership.

[...]
> 
> Does anyone have a clue?

My guess (and yes our (convex) ksh had it too, it's worse if you have more 
than one processor in the system).

Stefan

> 
> Leo.
> 

--
Stefan Grefen                          Convex Computer GmbH, Frankfurt, Germany
grefen@convex.com		       Phone: +49-69-665270
fortune: "You can't make a program without broken egos."