Hello,
Thanks to all who responded to my querry about the memory problem:
Dave Cherkus <cherkus_at_UniMaster.COM>
alan_at_nabeth.cxo.dec.com
<jyoti_at_qcav01.enet.dec.com>
"Hellebx Knut" <bgk1142_at_bggfu2.nho.hydro.com>
"Paul E. Rockwell" <rockwell_at_rch.dec.com>
We think we have found the actual problem, though the reporting of the
symptoms is a little confusing.
Just as a background, we have been running with "lazy" swap by having
renamed /sbin/swapdefault to something else. We haven't had any swap
related problems since that change. We had the -terminate option in
/usr/lib/X11/Xserver to make X restart after each session ever since
the X problems were discovered back in v1.2. However, every once in a
while we still have a problem with the dxsession in that windows move
around very slowly with the mouse, and dxterm core dumps upon exit.
Seems like there's still problems with it. We have to stay with v1.3a
because I wrote a CAM driver to talk to one of our custom hardware, and
it simply will not work under v2.x or v3.x of OSF. We don't have the
time to chase down either the dxsession problem or the CAM problem, but
if anyone can offer any info on those, it will be greatly appreciated.
Now, to the our problem of rsh:
The program in question runs in a big loop, with each iteration
generating some data files, at the end of each interation we call
system() to execute an rsh to copy these files and any subdirectories to
a remote system. It turns out that this remote system is an old
MASSCOMP with limited resources running an operating system with lots of
known bugs, including memory leaks and flaky TCP/IP drivers. After
about 18 iterations of processing/transferring, the Alpha reports the
rsh "Not enough core" error. We changed our program to hold its
position at the point of failure. When it did fail, we tried an rsh
manually from the command line, and it responded the same way. Then we
tried the same rsh to a different system, it worked! Looking more
closely at the MASSCOMP, we find that its system memory is almost
completely sucked up by the server process that was working with the
client on the Alpha. We couldn't do much of anything on the MASSCOMP at
this point; including a telnet attempt from the Alpha, which responded
with:
telnetserver: /etc/login: Not enough core
Connection closed by foreign host.
So the problem was on the MASSCOMP all along. But, the thing that had
us chasing our tail was the way the Alpha reported it:
/usr/bin/rcp: Not enough core
This made us think that the was having problems, when the problem was on
the remote system. I don't know why it didn't say something more explicit,
but we'll have to remember to trust the Alpha more in the future.
thanks again to all who responded
eugene chu
Received on Wed Feb 01 1995 - 14:57:44 NZDT