remote execution of a Veritas process hangs

[Dan Copeland]

remsh executing a Veritas script (ltid) hangs w/ no return. Executing it locally works fine. The remsh worked fine before we put the 11.0 Dec 2002 patch bundles on.

Any thoughts?

tia,
Frank

[Michael Steele_2]

.rhosts
rlogin
rcp
remsh

If you can rlogin you can remsh. All of these are dependent upon the .rhosts file within $HOME.

vi $HOME/.rhosts

You can see everything with 'tcpdump' since you're remotely connected over the network.

[Michael Steele_2]

Threads that may or may not be of assistance.

http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0x83ac72234586d5118ff00090279cd0f9,00.html

http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0xb719543254bfd611abdb0090277a778c,00.html

[Steven E. Protter]

If the target server has a file called /var/adm/inetd.sec it could be blocking access from your Veritas server.

SEP

[Dan Copeland]

All remsh, rcp, and rlogin functionality is working correctly for every command except the Veritas ltid command and this command executes correctly it's just that the remote server where the remsh is executed from never gets a return from the remsh. If you log on to the target server and kill the ltid process only then does the remsh command return.

[Frank Slootweg · Accepted solution]

What often helps is using remsh's "-n" option and specifically redirecting standard input, output and error, i.e.

remsh host -n command /dev/null 2>/dev/null

If output/error should be kept, then redirect to a real file.

[Tim Sanko]

Frank,

Veritas uses UDP sockets. It is not guarenteed to make connection. Check your overall network bandwidth used. I have seen inconsistant results with 30% bandwidth used across silkworm 3800 multi-gigabit fibre backbone.

IMHO look at isolating the backup VLAN if possible and trace,trace,trace and then start beating on Veritas if there are no errors found at cards or ports.

Tim

[Dan Copeland]

Thanks Frank, the -n w/ redirects worked...