Bug 813 - Scp to s Solaris 9 box gives "exit status 1" although file is delivered.
Summary: Scp to s Solaris 9 box gives "exit status 1" although file is delivered.
Status: CLOSED INVALID
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: scp (show other bugs)
Version: 3.8p1
Hardware: SPARC Solaris
: P2 normal
Assignee: OpenSSH Bugzilla mailing list
URL:
Keywords:
: 905 (view as bug list)
Depends on:
Blocks:
 
Reported: 2004-03-17 20:05 AEDT by Stefan Sundman
Modified: 2005-04-07 04:50 AEST (History)
2 users (show)

See Also:


Attachments
Debug from client and server side (9.56 KB, text/plain)
2004-03-17 20:06 AEDT, Stefan Sundman
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Sundman 2004-03-17 20:05:04 AEDT
When doing scp from a Solaris 8 (openssh 3.8p1) to a Solaris 9 (Sun Secure 
Shel) i get "exit status 1" even though the file is delivered.

p950sts@sshgw1$ scp junk 10.137.52.240:~/; echo $?; echo $?
p950sts@10.137.52.240's password: 
junk                                          100%   11KB   0.0KB/s   00:00    
1

Have done lots of tests with different OS versions (i.e. 5.6, 7, 8, 9).
When using openssh on serverside there is no problem.
The problem only occurs when doing a scp to a Solaris 9 Sun SecureShell (with 
ssh pathes installed).
The problem does not occur when serverside uses the NISPlus naming service.

Regards 
Stefan
Comment 1 Stefan Sundman 2004-03-17 20:06:36 AEDT
Created attachment 573 [details]
Debug from client and server side
Comment 2 Darren Tucker 2004-03-17 23:38:55 AEDT
What result does this give?
ssh sol9box "exit 0" ; echo $?
Comment 3 Stefan Sundman 2004-03-18 01:26:12 AEDT
p950sts@sshgw1$ ssh 10.137.52.240 "exit 0"; echo $?
p950sts@10.137.52.240's password: 
0

Gives 0.
Comment 4 Darren Tucker 2004-03-18 09:16:41 AEDT
Does scp'ing to the sol9 box itself give the correct error code?  ie
sol9box$ scp junk sol9box:/tmp ; echo $?

Can you try temporarily swapping the scp on the Solaris 9 box for OpenSSH's and
see if that works?
Comment 5 Stefan Sundman 2004-03-18 21:47:49 AEDT
No, 

scp'ing the sol9box will not produce any error output and it exits with a 0, I 
have only seen this problem between Sol 7 & 8 to sol9. 

One strange thing is that this problem does not occur on Sol9 boxes using 
NISPlus.

The swapping of scp did not produce anything new, same result as before.
Comment 6 Darren Tucker 2004-03-21 16:25:34 AEDT
I've been meaning to install Solaris 9, this finally gave me an excuse.  I can
reproduce it with OpenSSH talking to SunSSH, but it seems very inconsistent:

$ for i in `seq 1 30`; do scp -q hello.c sol9box:/tmp ; echo -n "$? "; done; echo
0 0 0 0 1 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0
Comment 7 Darren Tucker 2004-03-21 16:48:42 AEDT
OK, I'm now pretty sure it's not the exit status of the remote "scp" command.

I replaced the Solaris /usr/bin/scp with the following shell script, and I still
get the inconsistent results.

#!/bin/sh
/usr/bin/scp.orig $*
exit 0
Comment 8 Darren Tucker 2004-03-21 18:15:14 AEDT
Hmmm.  Firstly, it looks like SunSSH's ssh doesn't collect the return code properly.

$ uname -a
SunOS sol9box 5.9 Generic_112233-11 sun4m sparc SUNW,SPARCstation-5
$showrev -p |grep 113273
Patch: 113273-05 Obsoletes:  Requires:  Incompatibles:  Packages: SUNWsshdu
$ /usr/bin/ssh -V
SSH Version Sun_SSH_1.0, protocol versions 1.5/2.0.
$ /usr/bin/ssh sol9box /usr/bin/true; echo $?
255

Because of this, I'm using "ssh" from OpenSSH 3.8p1 for the rest of these tests.

$ dd if=/dev/zero of=tmpfile bs=1k count=5
$ for i in `seq 1 30`; do /usr/local/bin/ssh <tmpfile sol9box "cat >/dev/null;
exit 0" ; echo -n "$? "; done; echo
255 0 255 0 255 0 255 255 0 0 0 255 0 255 0 0 255 0 255 0 255 0 255 255 0 255 0
255 0 255

For comparison, here's the output of the same command on Solaris 8 with
OpenSSH's sshd (3.7.1p2):
$ for i in `seq 1 30`; do /usr/local/bin/ssh <tmpfile sol8box "cat >/dev/null;
exit 0" ; echo -n "$? "; done; echo
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

Conclusion: SunSSH's sshd does not always provide correct return codes when
dealing with input to non-interactive commands.  Report the bug to Sun, or
install OpenSSH.
Comment 9 Damien Miller 2004-03-21 18:29:43 AEDT
I bet that Sun is using one of the broken hang-on-exit "fixes"
Comment 10 Stefan Sundman 2004-03-21 20:42:20 AEDT
Thanks, that helped a lot!
I'll contact Sun and see what they can do. I'll report back as soon as I get 
more info. 
Comment 11 Roland Mainz 2004-03-31 03:12:49 AEST
Darren:
Can you take a quick look at this issue, please ?
Comment 12 Damien Miller 2004-04-14 12:24:20 AEST
Mass change of RESOLVED bugs to CLOSED
Comment 13 Darren Tucker 2004-08-29 21:31:38 AEST
*** Bug 905 has been marked as a duplicate of this bug. ***
Comment 14 Aleksandar Milivojevic 2005-04-07 04:50:38 AEST
I was doing some testing, and the strange thing is that SunSSH server gives
wrong exit status only when using newer versions of openssh on the client side.

For example,

Red Hat 7.3 as client (openssh 3.1) is OK
Fedora Core / RHEL4 as client (openssh 3.9) gives error
Fedora devel as client (openssh 4.0) gives error

Unlike Darren's results, the results I got when testing were consistent (as in
"every single time").  OpenSSH 3.1 on client side always works correctly. 
OpenSSH 3.9 and newer on client side always gives non-zero exit status (but file
transfer itself is OK).

Could it be that something changed in OpenSSH that triggers this behaviour in
SunSSH server?  Maybe OpenSSH isn't as innocent as it might look on a first glance?