scp gives Bus Error

[MikeL_4]

I am able to log into 11V3 server via ssh with no problem...

But when I try to do an scp, either to or from the server I am getting the following error:

=>scp ./test.sh labserv1:/tmp/test.sh
Bus error(coredump)
lost connection
=>

Not sure where to look for the cause, if anyone can give some direction...

I did try to upgrade Secure Shell but that didn't resolve issue...

[James R. Ferguson · Accepted solution]

Hi Mike:

You might see if you have patch PHCO_40072. If not, try applying it. The patch notes indicate that "An ssh login sometimes does not behave as expected."

Regards!

...JRF...

[MikeL_4]

I first downloaded the suggested patch, and running the create_ depot_hpux.11.31
Also failed with a core dumpâ ¦.

root:>ls -al
total 1728
drwxr-xr-x 2 root sys 8192 May 22 15:18 .
drwxr-x--- 4 root sys 8192 May 22 15:17 ..
-rw-r--r-- 1 21164 12753 318121 Sep 3 2009 PHCO_40072
-rw-r--r-- 1 21164 12753 1779 Feb 16 10:11 README_hp-ux
-rw------- 1 root sys 186464 May 22 15:18 core
-rwxr-xr-x 1 21164 12753 5761 May 22 15:15 create_depot_hpux.11.31
-rw-r--r-- 1 root sys 330240 May 22 15:17 hpux__11.31_05220715.tar
-rw-r--r-- 1 21164 12753 80 May 22 15:15 patch_manifest
root:>./create_depot_hpux.11.31
Bus error(coredump)
root:>

I created the depot on another server, but it told me it is already installed..
NOTE: The fileset "PHCO_40072.CORE2-SHLIBS,r=1.0" is already installed.

[Dennis Handly]

>Bus error(coredump)

What does "file core" show for the two cases?
You may have a kernel config problem if two different executables are failing.

>root:>./create_depot_hpux.11.31
Bus error(coredump)

Which is failing here?

>it told me it is already installed.

You could use "swlist PHCO_40072" to check that.

[singh sanjeev]

check if any file system is full ...i am guessing.

[MikeL_4]

No file systems are 100% Full:
root:>bdfm
Server: osglbhp1 >> Date: Sat May 22 20:48:20 EDT 2010
File-System Mbytes Used Avail %Used Mounted on
/dev/vx/dsk/rootdg/rootvol 8192 481 7650 6% /
/dev/vx/dsk/rootdg/standvol 8192 630 7502 8% /stand
/dev/vx/dsk/rootdg/varvol 32.0g 6508 25.4g 20% /var
/dev/vx/dsk/rootdg/usrvol 32.0g 3016 28.8g 9% /usr
/dev/vx/dsk/rootdg/tmpvol 8192 20 8107 0% /tmp
/dev/vx/dsk/rootdg/homevol 8192 1256 6900 15% /osg1
/dev/vx/dsk/rootdg/optvol 32.0g 6941 25.0g 21% /opt
root:>

strings command on core files from scp and create_depot_hpux.11.31 are in attached file: strings_on_core_files

[MikeL_4]

Note sure if the last attachment came through correctly...

I've attached core from scp error: scp.core

[MikeL_4]

I've attached core from the create_depot_hpux.11.31 error:

[Dennis Handly]

>strings command on core files from scp and create_depot_hpux.11.31

This is next to useless. Though it does seem to indicate that ksh is aborting. So your system seems really sick.
Again, what does file(1) show for each?

>I've attached core from scp error: scp.core

Even more useless. A corefile is useless except on your system. Only gdb's packcore is transportable. Here a stack trace may be helpful.
http://www.hp.com/go/wdb

[MikeL_4]

root:>file ./scp.core
./scp.core: ELF-32 core file - IA64 from 'disaster_files' - received SIGBUS
root:>file ./create_depot_hpux.11.31.core
./create_depot_hpux.11.31.core: ELF-32 core file - IA64 from 'create_depot_hpux.11.31' - received SIGBUS
root:>

[Dennis Handly]

>scp.core: ELF-32 core file - IA64 from 'disaster_files' - received SIGBUS

That's strange. scp invokes disaster_files?
Or is disaster_files a ksh script that invokes scp?

>create_depot_hpux.11.31.core: ELF-32 core file - IA64 from 'create_depot_hpux.11.31' - received SIGBUS

You might want to do a swverify to see if ksh has been corrupted.

When did everything last work? And kernel parm changes?

[MikeL_4]

Disaster_files is a script that runs weekly out of cron, collects certain files and information, then scpâ s the data back to a management server for storageâ ¦ This was probably run last when I did the file on the core file, thus thatâ s why it showed up in the outputâ ¦ I just ran it again and it gave:
root:>scp ./test.sh labserv1:/tmp/test.sh
Bus error(coredump)
root:>file ./core
./core: ELF-32 core file - IA64 from 'scp' - received SIGBUS
root:>

I ran the swverify, and this server has big problems, looks like a rebuild of this server is in orderâ ¦

* Beginning Analysis
* Session selections have been saved in the file
"/root/.sw/sessions/swverify.last".
ERROR: "osglbhp1:/": 40 software selection(s) are corrupt.
ERROR: "osglbhp1:/": 1 check scripts failed.
ERROR: "osglbhp1:/": The software dependencies for 156 products or
filesets cannot be resolved.
WARNING: "osglbhp1:/": 123 files had warnings during this operation.
ERROR: "osglbhp1:/": 1635 files had errors during this operation.
* The analysis phase failed for "osglbhp1:/".
* Verification had errors.

There was no changes made to this server, it wasup and running just fine, when someone in the Operations center powered it off my mistake, and this is the resultâ ¦

[Dennis Handly]

>this server has big problems, looks like a rebuild of this server is in order

Most likely. Or a restore of an ignite image.

ERROR: "osglbhp1:/": 40 software selection(s) are corrupt.
ERROR: "osglbhp1:/": 1 check scripts failed.
ERROR: "osglbhp1:/": The software dependencies for 156 products or filesets cannot be resolved.

I'm surprised about the "dependencies" issue.

>ERROR: "osglbhp1:/": 1635 files had errors during this operation.

You may want to look closer at this to see if anything missing or bad permission.

>powered it off my mistake, and this is the result

Yes, that could happen. Any fsck(1m) errors?