Determining problems with rah (Linux, UNIX)
This topic gives suggestions on how to handle some problems that you might encounter when you are running rah.
- rah hangs (or takes a very long time) This problem might be caused because:
- rah has determined that it needs to buffer output,
and you did not export
RAHCHECKBUF=no
. Therefore, before running your command, rah sends a command to all computers to check the existence of the buffer directory, and to create it if it does not exist. - One or more of the computers where you are sending your command is not responding. The rsh command will eventually time out but the time-out interval is quite long, usually about 60 seconds.
- rah has determined that it needs to buffer output,
and you did not export
- You have received messages such as:
- Login incorrect
- Permission denied
Either one of the computers does not have the ID running rah correctly defined in its /etc/hosts file, or the ID running rah does not have one of the computers correctly defined in its .rhosts file. If the DB2RSHCMD registry variable has been configured to use ssh, then the ssh clients and servers on each computer might not be configured correctly.
Note: You might need to have greater security regarding the transmission of passwords in clear text between database partitions. This will depend on the remote shell program you are using. rah uses the remote shell program specified by the DB2RSHCMD registry variable. You can select between the two remote shell programs: ssh (for additional security), or rsh. If this registry variable is not set, rsh is used. - When running commands in parallel using background remote shells,
although the commands run and complete within the expected elapsed
time at the computers, rah takes a long time to
detect this and put up the shell prompt.
The ID running rah does not have one of the computers correctly defined in its .rhosts file, or if the DB2RSHCMD registry variable has been configured to use ssh, then the ssh clients and servers on each computer might not be configured correctly.
- Although rah runs fine when run from the shell
command line, if you run rah remotely using rsh,
for example,
rah never completes.rsh somewher -l $USER db2_kill
This is normal. rah starts background monitoring processes, which continue to run after it has exited. Those processes normally persist until all processes associated with the command you ran have themselves terminated. In the case of db2_kill, this means termination of all database managers. You can terminate the monitoring processes by finding the process whose command is rahwaitfor and kill process_id>. Do not specify a signal number. Instead, use the default (15).
- The output from rah is not displayed correctly,
or rah incorrectly reports that $RAHBUFNAME does
not exist, when multiple commands of rah were issued
under the same $RAHUSER. This is because multiple concurrent executions of rah are trying to use the same buffer file (for example, $RAHBUFDIR or $RAHBUFNAME) for buffering the outputs. To prevent this problem, use a different $RAHBUFNAME for each concurrent rah command, for example in the following ksh:
or use a method that makes the shell choose a unique name automatically such as:export RAHBUFNAME=rahout rah ";$command_1" & export RAHBUFNAME=rah2out rah ";$command_2" &
RAHBUFNAME=rahout.$$ db2_all "....."
Whatever method you use, you must ensure that you clean up the buffer files at some point if disk space is limited. rah does not erase a buffer file at the end of execution, although it will erase and then re-use an existing file the next time you specify the same buffer file.
- You entered
and received the message:rah '"print from ()'
ksh: syntax error at line 1 : (' unexpected
Prerequisites for the substitution of () and ## are:- Use db2_all, not rah.
- Ensure a RAHOSTFILE is used either by exporting RAHOSTFILE or by defaulting to your /sqllib/db2nodes.cfg file. Without these prerequisites, rah leaves the () and ## as is. You receive an error because the command print from () is not valid.
For a performance tip when running commands in parallel, use | rather than |&, and use || rather than ||& or ; unless you truly need the function provided by &. Specifying & requires more remote shell commands and therefore degrades performance.