I am attempting to sftp an MVS dataset by issuing the following command:
get '//userid.mvs.records' records. When I issue 'cat records' I noted I received only a partial file.
On the MVS log I received the following error:
BPXF204I (BPXONIT) Jul 1 12:31:54 MVSSYS/USERID SSHDAEMN 549 sshd 67109027 : fatal : xrealloc : out of memory (new_size 937984).
On the Coz log I received the following error:
[00521] debug1: request 68: sent date len 32768
CEE5213S The signal SIGPIPE was received.
SSHD XREALLOC OUT OF MEMORY
I apologize, but I have a bunch of questions:
What version of Co:Z SFTP server are you using?
What version of IBM Ported Tool SSH are you using?
What SFTP client are you using?
The error message that you are getting is from IBM Ported Tools OpenSSH (sshd). It looks like it is trying to allocate 937k of memory, which doesn't sound right. You may wish to report this problem to IBM.
The "CoZ Log" is the Co:Z SFTP server logfile, right? Are these the only messages that you got? The "SIGPIPE" is expected, since IBM sshd starts the Co:Z sftp-server as a child process with a pipe connection. So if sshd crashes, this is what you would see from Co:Z sftp-server.
Did you get an error message on your client? I see no way that the client could have gotten the correct SFTP packet responses that would tell it that the file download was complete in this scenario.
What version of Co:Z SFTP server are you using?
What version of IBM Ported Tool SSH are you using?
What SFTP client are you using?
The error message that you are getting is from IBM Ported Tools OpenSSH (sshd). It looks like it is trying to allocate 937k of memory, which doesn't sound right. You may wish to report this problem to IBM.
The "CoZ Log" is the Co:Z SFTP server logfile, right? Are these the only messages that you got? The "SIGPIPE" is expected, since IBM sshd starts the Co:Z sftp-server as a child process with a pipe connection. So if sshd crashes, this is what you would see from Co:Z sftp-server.
Did you get an error message on your client? I see no way that the client could have gotten the correct SFTP packet responses that would tell it that the file download was complete in this scenario.
You may wish to use the current version of Co:Z sftp-server, since it has better signal/exception handling (added in 1.3.0 and 1.4.1). See:
http://dovetail.com/docs/cozinstall/changes.html
However, the "xrealloc failed" message is from sshd (IBM Ported Tools). If you Google "sshd fatal xrealloc out of memory", you will find several threads in the OpenSSH list. From my reading, it looks like this could either be a bug in OpenSSH sshd or might just be a OMVS memory limit problem with the forked sshd children (which run in a separate OMVS address space). If you haven't already, I would suggest that you apply the latest maintenance for Ported Tools OpenSSH (which also include security patches), and contact IBM if the problem persists.
Please let us know if you find a resolution or if we can assist.
http://dovetail.com/docs/cozinstall/changes.html
However, the "xrealloc failed" message is from sshd (IBM Ported Tools). If you Google "sshd fatal xrealloc out of memory", you will find several threads in the OpenSSH list. From my reading, it looks like this could either be a bug in OpenSSH sshd or might just be a OMVS memory limit problem with the forked sshd children (which run in a separate OMVS address space). If you haven't already, I would suggest that you apply the latest maintenance for Ported Tools OpenSSH (which also include security patches), and contact IBM if the problem persists.
Please let us know if you find a resolution or if we can assist.
We have seen other situations where IBM Ported Tools fails with this "xrealloc" message. In one case, we were able to fix the problem by changing the LE options for IBM Ported Tools to set the inital HEAP size, so we feel that there is some kind of memory management error. We are ourselves working with IBM to help to resolve this issue.
If you (or anyone) are able to reproduce this problem, we would encourage you to open a PMR with the IBM support center.
Also, although your problem is occuring when running the IBM 'sshd' program, rather than the "ssh" client program as we found earlier, we can probably figure out a way to set the same LE option in your SSHD server to see if it corrects the problem (assuming that you can recreate it). But, since this is a storage allocation in IBM code which runs in a separate address space from Co:Z SFTP, we feel that IBM should be involved as the symptoms point clearly to their product.
If you (or anyone) are able to reproduce this problem, we would encourage you to open a PMR with the IBM support center.
Also, although your problem is occuring when running the IBM 'sshd' program, rather than the "ssh" client program as we found earlier, we can probably figure out a way to set the same LE option in your SSHD server to see if it corrects the problem (assuming that you can recreate it). But, since this is a storage allocation in IBM code which runs in a separate address space from Co:Z SFTP, we feel that IBM should be involved as the symptoms point clearly to their product.