openssh unix dev - Feb 2001 - SCO 5.0.5 (i686-pc-sco3.2v5.0.5), scp and the -n option

Ok, using openssh-SNAP-20010126.tar.gz, two versions of the server both compiled
with the
configure commands as below, one with USE_PIPES defined
and one without.  This is on SCO OpenServer 5.0.5 (using SCO dev
environment, SCO make, etc.)  The client is always linux, openssh
2.3.0p1.

export CCFLAGS='-L/usr/local/lib -I/usr/local/include'
./configure --sysconfdir=/etc/ssh --with-rsh=/usr/bin/rcmd \
--exec-prefix=/usr --without-egd-pool

Host: i686-pc-sco3.2v5.0.5

I used two versions of a simple shell script to invoke ssh and scp
repeatedly, the first does not specify the -n option to ssh, and
second version uses -n on all the ssh invocations. 

The commands:
ls -ld .
ssh -V
'cat /etc/hosts|grep localhost'
scp /etc/hosts root@$host:/tmp/hosts.foo
/usr/bin/X11/xterm -sb -sl 1000 -T $host -e '/tmp/test-scr.sh'

(The /tmp/test-scr.sh script just runs find /etc and sleeps for 2
seconds.) 

Now, on the machine without USE_PIPES (that is the unmodified snap
20010126) the non -n script runs just fine repeatedly... except that
although execution of the script continues past the invocation of scp,
scp doesn't exit, they just pile up on the client side. The sshd
for scp doesn't exit either until you kill ssh on the client side. 

When the non -n script is run against a server with USE_PIPES,
everything seems to run just fine, scp exits and leaves no residue.

Now, if I run the -n version of the script,

On the server without USE_PIPES, every command invoked hangs and the
script won't continue executing unless you kill the corresponding sshd
or ssh process.  Sometimes it hangs before I get my input back,
sometimes not.  Strangely, I seem to only get input back from ssh -V,
and not ls or the cat|grep command.  scp does copy the file as
expected. (scp behaves as above to this server) The xterm does appear,
and close, but the sshd still hangs around along with the ssh.

If I try the -n version of the script on the USE_PIPES server,
everything works absolutely fine.  

Essentially I've reported these same type of problems in August, but
now the command hangs instead of dying with a  
Disconnecting: Command terminated on signal 13.
error message.  (USE_PIPES fixed it for me then, too.)

The real question (for me) here is in what circumstances do I need to
use -n?  I would swear that in the past, I have needed -n to keep
shell scripts from hanging on invocations of rsh/rcmd.  Now, I can't
duplicate that to save me. (Either with rsh/rcmd or ssh.)  It appears
that I don't even need -n to get X applications to work correctly.  If
it weren't for the problems with scp hanging around I would just drop
the -n and forget about USE_PIPE entirely, but -n ought to
work. However, since I can't seem to find a concrete use for the
option, that point may be moot. 

I would really like to see if anyone can duplicate this. Alternately you
could just take my word for it and put USE_PIPES back into the
configure.in script for *-*-sco3.2v5* ;)

Aran

On Mon, 5 Feb 2001, Aran Cox wrote:
[..]
> I would really like to see if anyone can duplicate this. Alternately you
> could just take my word for it and put USE_PIPES back into the
> configure.in script for *-*-sco3.2v5* ;)
> 
USE_PIPES went back into sco3.2v5 on 1/28/2001.  Please verify against the
latest snapshot.

- Ben

On Mon, Feb 05, 2001 at 06:13:21PM -0600, Aran Cox
wrote:
> 
> The real question (for me) here is in what circumstances do I need to
> use -n?  I would swear that in the past, I have needed -n to keep
> shell scripts from hanging on invocations of rsh/rcmd.  Now, I can't
> duplicate that to save me. (Either with rsh/rcmd or ssh.)  It appears
> that I don't even need -n to get X applications to work correctly.  If
> it weren't for the problems with scp hanging around I would just drop
> the -n and forget about USE_PIPE entirely, but -n ought to
> work. However, since I can't seem to find a concrete use for the
> option, that point may be moot. 
> 
Ok, I went out and answered my own question.  If you write a script like
this:  

while read host; do
[rs]sh $host ls -ld .
done

And pass a list of hosts via stdin, only the first host gets
[rs]sh run on it.  Then the script just exits.  [rs]sh sucks up
the rest of stdin, unless you prevent it from doing so with the
-n option.  

I don't quite understand why ssh or rsh would read stdin until
it's empty without the executed program on the other end 
requesting anything of stdin.  Would doing it otherwise have 
been needlessly complex?  Or was that just the behaviour of
rsh and hence the behaviour of ssh?

Aran