Consultor Eletrônico



Kbase 16177: Remote Command Unix (rcmd) not returning to parent tty
Autor   Progress Software Corporation - Progress
Acesso   Público
Publicação   10/05/1998
Remote Command Unix (rcmd) not returning to parent tty

This KBase is being generated to assist customers that may experience
difficulty with the remote command (rcmd) being used to spawn database
servers. The problem appears when you migrate from 6.2L of Progress
to version 6.3F or version 7.3+. The behavior is that when invoking
the remote command (rcmd) process to execute a script, the script
spawns and servers are started. However, tty cursor control is not
returned to the calling window.

The problem is one that adding nohups or placing the job in background
still does not get your tty cursor control back to the calling tty.
The only way you get back tty control is if you proshut the database
server using proshut. Once the process terminates, then the calling
tty / shell regains tty control.

You can workaround this problem by redirecting standard out and
standard error to (-) which causes tty control to be returned to the
calling tty / shell. The syntax would be:
rcmd hostname "script 1>&- 2>&-"

The problem is due to rcmd or remsh invoking a shild process which
runs a script. The nature of rcmd or remsh is to not return control
back to the calling tty / shell until the job it is calling is ran
to completion. In the case of starting a server, the job will never
run to completion, as the server will remain in a state of running,
until you issue the proshut command against that server process.
The workaround above make the rcmd return control prior to the job
running to completion. Thus meeting the expectation of spawning a
server and then regaining tty control so the operator may continue
working without the tty appearing to be locked.

This is not a Progress bug. This is how rcmd and remsh work. This
information is documented in the remsh man page if you need additional
feedback regarding its functionality.

Progress Software Technical Support Note # 16177