1830123 Members
24916 Online
109998 Solutions
New Discussion

r-commands dying

 
Ken Werneburg
Occasional Advisor

r-commands dying

I have two L2000 systems on a ffffff00 network, running HP-UX 11.0 and here is my problem:
r-command like remsh, rexec and such will die on the target node when trying to open a port back to the initiator node.
ie
remsh node2 ls
rexec node2 bdf
will crap out with the following messages
rcmd: primary connection shut down
rexec: primary connection shut down

The weird thing is I can do an rlogin or a remsh, it's only when I pass them a command to run that this happens. Without the commands the shell opens with no problems.
9/10 times it will core-dump.
Moreover, the same activity happens if I try to open the r-command to the same node, i.e. on node1 I do
remsh node1 ls
I see the same response. So it appears that the port is opening correctly just for a remote shell or for an rlogin, but just for opening added commands through the remote shell or remote login that it runs into problems.
I'm fairly sure I'm fully patched...
Anyone seen this?
10 REPLIES 10
James Odak
Valued Contributor

Re: r-commands dying

Just a suggestion
try doing it like this
remsh node1 "/usr/bin/ls"
and rexec node1 "/usr/bin/bdf"

use the whereis command to find the full path of the command

hope this helps
Ken Werneburg
Occasional Advisor

Re: r-commands dying

Thanks, but no dice. It seems as though there's something unhappy about the socket it's trying to open on return. The remsh and rlogin work fine without the command, but die when *anything* is specified, whether a full path, quoted, not, etc.
Antoanetta Naghiu
Esteemed Contributor

Re: r-commands dying

Check /etc/inetd.conf for remshd and rexecd to see how they are started. You can try as well to check .rhosts or hosts.equiv files. If you execute the r-commands as a regular user, check if that user can access the remote box.
That specific message ?primary connection shut down? can occur if you are using inetd.sec (see /var/adm/inetd.sec file).
Ken Werneburg
Occasional Advisor

Re: r-commands dying

exec stream tcp nowait root /usr/lbin/rexecd rexecd

shell stream tcp nowait root /usr/lbin/remshd remshd

No surprises there.

.rhosts exists and is happy; I can do a basic remsh without command with no problems.

/var/adm/inetd.sec does not exist...

Wahhhhh.....
Antoanetta Naghiu
Esteemed Contributor

Re: r-commands dying

Try to create /var/adm/inetd.sec under root:sys ownership with 444 permission (-r--r--r-- root as owner, sys as a group).
In only one L machine that I have, here you go the /var/adm/inetd.sec. See man inetd.sec as well. (you can just cut off the last line in the file; that is for IT/O.
I don't know if counts or not, but in /etc/inetd.conf beside the line that you mentioned you have, I do have one more:
kshell stream tcp nowait root /usr/lbin/remshd remshd -K
So, add this line in /etc/inetd.conf and have the /var/adm/inetd.sec. Any luck? Still the same error?

Ken Werneburg
Occasional Advisor

Re: r-commands dying

Tried with and without /var/adm/inetd.sec and still no luck.
eshell, elogin, kshell, klogin are also both listed, but they're not the ones I'm using...
Tim Malnati
Honored Contributor

Re: r-commands dying

Something has to be different on these two machines from what you normally find on a typical 11.x machine. This suggests that something has been modified somewhere locally from what comes out of the box (so to speak). The first place I would look for modifications is somewhere in /etc and keep permissions in mind too. The problem symptoms suggests networking but it could be a problem with login processing also. How about /etc/profile /etc/PATH /home//.profile and your environment variables? Are there any NFS cross mounts between these machines and are any quotas active? Is this a ServiceGuard arrangement? Is a non-standard shell in use? Are there multiple network connections on these machines?

Obviously, I don't have a clear cut answer for you, but maybe some new places to look.
Paul Hite
Trusted Contributor

Re: r-commands dying

I also have a couple of questions. Can you tell us a little about your network topology, for instance are these two systems on the same lan segment, if not what is between them? Also, are you using ndd or adb or anything to modify any kernel networking parameters on either of these systems?
Ken Werneburg
Occasional Advisor

Re: r-commands dying

Great suggestions!
/etc/PATH /etc/profile are straight, standard defaults. No surprises there. I've thought about $HOME/.profiles, but it happens with every user I've tried, not just root.
Moreover, it happens with any different shell, I've tried sh, csh, ksh...
There are no nfs mounts or exports, no quotas.

This *is*, however, an MC/ServiceGuard environment. We have two L2000s set up as follows:

lan0 - heartbeat (192.168..)
lan1 - external address (38.144..)
lan2 - standby for failure, unconfigured.

The heartbeat is just a crossover between the two, lan1 is on a 255.255.255.0 network, patched into a switch.
/etc/hosts shows
lan0 hb1
lan1 node1 node1alias.fully.qualified
127.0.0.1 loopback

Aside from that we have no ndd modifications in place, like ip_forwarding or the like and with only 2 active NICs I don't think the OS would be turning that on.

But I *do* believe it would be networking that is causing our problems. Just a hunch.
Paul Thomson_2
Super Advisor

Re: r-commands dying

I have just had this and increased inetd logging minus l on the end of inetd , it showed in syslog afterwards

remshd[6972]: usage: remshd [-ln]
So I checked inetd.conf and this had a -m on the end of remshd, once removed and things restarted its OK.

Argh ye land lovers !