| Title: | DIGITAL UNIX (FORMERLY KNOWN AS DEC OSF/1) |
| Notice: | Welcome to the Digital UNIX Conference |
| Moderator: | SMURF::DENHAM |
| Created: | Thu Mar 16 1995 |
| Last Modified: | Fri Jun 06 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 10068 |
| Total number of notes: | 35879 |
performing the shell command $ rsh deccc10 'echo a; sleep 10; echo b' | ( read line ) causes a rsh process to wait for input from my terminal. The following outputs (ps -ft <tty>) reflect the situations 1st) while waiting (sleep 10) 2nd) after getting back the shell prompt $ ps -ft p4 USER PID PPID %CPU STARTED TTY TIME COMMAND pfeifer 21813 21811 0.0 15:46:51 ttyp4 0:00.75 ksh pfeifer 21912 21813 0.0 16:10:29 ttyp4 0:00.04 rsh deccc10 echo a; sleep 10; echo b pfeifer 21916 21912 0.0 16:10:29 ttyp4 0:00.00 rsh deccc10 echo a; sleep 10; echo b $ ps -ft p4 USER PID PPID %CPU STARTED TTY TIME COMMAND pfeifer 21813 21811 0.0 15:46:51 ttyp4 0:00.75 ksh pfeifer 21916 1 0.0 16:10:29 ttyp4 0:00.00 rsh deccc10 echo a; sleep 10; echo b It seems that the second rsh process (the son of the original rsh process) is not correctly terminated when its remote process produces output (which must come along with a new (!!!) TCP packet) and its standard output is closed too soon. These commands are the break-down of a relatively complex command, which is used at customer site to read a cpio file from a tape which is mounted on some remote machine. Therefore a popen/fgets/pclose sequence is used, but fgets() doesn't get EOF and therefore is hanging ... Clearly for me, this is a bug of rsh. But, has anyone out there any suggestions ??? [Posted by WWW Notes gateway]
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 9636.1 | shell is part of it | SMURF::DUSTIN | Tue Apr 29 1997 12:21 | 7 | |
It looks like something to do with the (read line) piece; if you
replace (read line) with "cat", it works fine. I'm not sure what
games the shell is getting caught up in, maybe a shell expert can
help out?
John
| |||||
| 9636.2 | NNTPD::"[email protected]" | Joachim Pfeifer | Tue Apr 29 1997 12:58 | 15 | |
re .1 I used the "read line" because this exactly reproduces the customer's problem. The fact of prematurely closing the read-side of the pipe (while the write-side wants to write something) seems to cause the rsh parent to die without cleaning up --> the rsh child continues to run, i.e. it does a read() on stdin. If this was done interactively, the rsh child will eventually terminate (reading one line of your keyboard input) - as soon as the operating system delivers one input line to it (-> you will be puzzled). [Posted by WWW Notes gateway] | |||||
| 9636.3 | NNTPD::"[email protected]" | Joachim Pfeifer | Wed May 07 1997 06:22 | 17 | |
Some new information:
the following command line is the shortest (we found)
which produces a hanging rsh process
$ rsh localhost echo b | :
the next one will definitly hang
$ ( 2>&3 rsh localhost echo b | : ) 3>&1 | cat
This hanging is forced by redirecting the stderr of rsh into the
outer pipe; so "cat" will not see EOF.
This last situation is exactly the customers problem when backing up
with rsh.
We consider this a bug in rsh - shall we QAR it ?
[Posted by WWW Notes gateway]
| |||||