rcp returning to parent shell

[Jim Sokolowsky]

All,

I've been chasing this problem for quite awhile and was wondering if anyone has seen it before. I've set up a number of these and never had this happen before. Also, I've ruled out the application part of it by hacking out just what I need. Here is the situation.

I have a pair of 4 CPU L2000 11.0 servers - one active and one standby. In order to get a copy of the database from the active, the standby issues a remote shell command to unload the database table. This works without incident.

The problem is with the rcp. The standby server is doing an rcp to get the unloaded file from the active machine. This works for small files, but the problem is with the large files I have, meaning those that are 25 MB or greater.

What I've found is that the file transfer completes, as I can get 25 MB across in about a minute or two. However, for the larger files, the rcp process doesn't return to the parent shell. The rcp is invoked and the file comes across. But when the transfer
is complete, it is as though the rcp doesn't terminate. After about two hours (I assume an rcp timeout), activity picks up and the parent
process continues.

There was nothing in the sniffer trace to show anything unusual. I set up another pair of nearly identically equipped servers in the
same timeframe with the same configuration and they don't act the same way.

If anyone has seen a similar problem, I'd be grateful for any insights you might have. Also, if anyone knows hot to debug what is going on, I'd like to know that too.

Thanks and best regards,

Jim

[Pete Randall · Accepted solution]

Jim,

Since your other pair of servers don't exhibit this problem, I'm tempted to look at patching differences. Searching for 11.0 rcp patches, I come up with PHKL_22677 and PHNE_23003 and PHNE_21767, along with a few others. Are you up to date on patches?


Pete

[Mark Greene_1]

In addition to the patches, run this:

UNIX95= ps -efH|head -1; UNIX95= ps -efH|egrep "inetd|rpc|mount"|grep -v grep; rpcinfo -p|egrep "service|nfs"; showmount -e; mount -p

and check the output. The ps listing should looks similar to this:

UID PID PPID C STIME TTY TIME CMD
root 811 0 0 Dec 13 ? 00:00 nfskd
root 907 1 0 Dec 13 ? 00:02 /usr/lib/netsvc/fs/automount/automount -f /etc/auto_master
root 1404 1 0 Dec 13 ? 02:11 /opt/dce/sbin/rpcd
root 806 1 0 Dec 13 ? 00:00 /usr/sbin/rpcbind
root 896 1 0 Dec 13 ? 00:00 /usr/sbin/rpc.lockd
root 890 1 0 Dec 13 ? 00:00 /usr/sbin/rpc.statd
root 1845 1 0 Dec 13 ? 00:00 /usr/sbin/rpc.mountd
root 1856 1 0 Dec 13 ? 00:24 /usr/sbin/inetd

Note that the lockd and statd processes need to be started together. If one is missing or has a considerably different date, then rpc is going to behave wierdly.

HTH
mark

[Jim Sokolowsky]

Thanks for the replies. Gave me some things to check out. However, lockd and statd have been started at the same time, and while the patches are not up to date (I looked for 'rcp' patches and of ten, I have only two), the patches loaded are the same on both pairs of servers.

I'll need to look some more, but is it possible that if they're using different LAN interfaces, that there might be a bug or a leak in one of the drivers?

Just a thought.

Jim

[Pete Randall]

Jim,

OK, then what about network issues? Are the NIC and switch set to the same speed/duplex combo. HP doesn't seem to do well with 100MB/Auto-negotiate and the standard recommendation is to hard code both the switch port and the NIC to 100FD (full duplex).


Pete

[Pete Randall]

Jim,

Sorry, forgot to add: use lanadmin to check the speed of the NIC. It's "lanadmin -x 0" where 0 is the PPA of your NIC, obtained from lanscan (but check the man page as I'm home and doing this from memory and I can't recall whether it's a capital X or a lower case x - one queries the other one sets).


Pete

[Bill Hassell]

rcp uses a lot of system resources since the packet sizes are not optimized for the speed of the link. You might want to change to ftp (which can be run in batch mde) and you'll probably see the problem disappear plus see a large decrease in the transfer time.

[Jim Sokolowsky]

OK, so I guess what I'm finding is that no one has ever really experienced this. I wanted to address the one suggestion about going to "ftp" over "rcp." Unfortunately, I'd have to bring up with the development group that a change be made to the design of the application. If this is what is needed, then I guess it's my only alternative. The other might be to do file compression to see if the file size goes below whatever ceiling is out there.

Thanks for the suggestions. I'll keep looking to see if anyone has anything new.

Jim