lamboot - Start a LAM multicomputer.
SYNTAX
lamboot [-bdhvxH] [<bhost>]
OPTIONS
-b Assume local and remote shell are the same. This
means that only one remote shell invocation is
used to each node. If -b is not used, two remote
shell invocations are used to each node.
-d Turn on debugging output. This implies -v.
-h Print the command help menu.
-s Close stdio on the local node.
-v Be verbose.
-x Run in fault tolerant mode.
-H Do not display the command header.
DESCRIPTION
The lamboot tool starts the LAM software on each of the
machines specified in the boot schema, <bhost>. The boot
schema specifies the hostnames of nodes to be used in the
run-time MPI environment, and optionally lists how may
CPUs LAM may used on each node. The user may wish to
first run the recon(1) tool to verify that LAM can be
started.
Starting LAM is a three step procedure. In the first
step, hboot(1) is invoked on each of the specified
machines. Then each machine allocates a dynamic port and
communicates it back to lamboot which collects them. In
the third step, lamboot gives each machine the list of
machines/ports in order to form a fully connected topol
ogy. If any machine was not able to start, or if a time
out period expires before the first step completes, lam
boot invokes wipe(1) to terminate LAM and reports the
error.
The <bhost> file is a LAM boot schema written in the host
file syntax. See bhost(5). Instead of the command line,
a boot schema can be specified in the LAMBHOST environment
variable. Otherwise a default file, bhost.def, is used.
LAM searches for <bhost> first in the local directory and
then in the installation directory under etc/.
In addition, lamboot uses a process schema for the indi
vidual LAM nodes. A process schema (see conf(5)) is a
description of the processes which constitute the
istrator maintains this file -- LAM/MPI users will gener
ally not need to change this file. It is also possible
for the user to customize the LAM software with a private
process schema.
Remote shell invocation
The remote shell program that is used to invoke commands
on remote hosts is set when LAM is configured. It is typ
ically rsh, but can be set to any value by the person who
setup/compiled LAM. This program can be overridden at
lamboot invocation time by setting the LAMRSH environment
variable to a suitable remote shell program. For example:
setenv LAMRSH "ssh -x"
This will force LAM to use the "ssh" client to invoke pro
grams on remote nodes, and ensure that "ssh" uses the -x
command line flag (to suppress the ssh 1.x client series
standard information banner that is normally output to the
standard error, which would cause lamboot to fail).
Normally, lamboot uses two remote shell invocations to
each node. The first remote shell invocation is used to
determine the user's shell on the remote node. The second
remote shell invocation is used to launch the desired LAM
binary on the remote node. If the -b switch is used, lam
boot will assume that the user's shell on all remote nodes
is the same as it is on the local node, and therefore only
one remote shell invocation is used, which is noticably
faster.
In either case, on remote nodes, if the user's shell is
not csh, tcsh, or bash, .profile is invoked by LAM before
invoking any LAM binary. This allows the user to setup
paths and any necessary environment before LAM binaries
are invoked (csh and tcsh users can put such setup in
their $HOME/.cshrc or $HOME/.tcshrc files; bash users can
put this setup in their $HOME/.bashrc file).
Closing stdio
The stdio of each LAM daemon on a remote host that is
launched by lamboot is closed by default. Normally, the
stdio of the LAM daemon launched on the local host is left
open so that the internal LAM tstdio(3) package works
properly. However, it is sometimes desirable to close the
stdio of the local LAM daemon as well. For example:
rsh somenode lamboot -s hostfile
This is because rsh waits for two conditions before exit
ing: lamboot to exit, and stdout / stderr to be closed.
Without -s, stdout / stderr would not be closed, and rsh
would hang even though lamboot had completed. -s causes
upon invocation, which will allow rsh to complete. Using
-s will not affect lamboot in any other way, but it will
prevent the tstdio(3) package from working properly.
Fault Tolerance
If the -x option is given, LAM runs in fault tolerant
mode. In this mode, nodes exchange ``heart beat'' mes
sages periodically to make sure all nodes are running and
the links connecting them are operational. When a node's
heart beats stop, it is declared ``dead'' and all LAM
nodes (and processes) are notified. This allows users to
write fault tolerant applications that can degrade grace
fully, or fully recover by replacing the defunct node with
another (see lamgrow(1)). Since this mode introduces a
performance penalty, it is not activated by default.
EXAMPLES
lamboot -v
Start LAM on the machines described in the default
boot schema. Report about important steps as they are
done.
lamboot mynodes
Start LAM on the machines described in the boot schema
mynodes. Operate silently.
FILES
$LAMHOME/etc/lam-bhost.def default boot schema file
$LAMHOME/etc/lam-conf.lam default process schema file
for LAM nodes
SEE ALSO
recon(1), wipe(1), hboot(1), tstdio(3), bhost(5), conf(5),
lam-helpfile(5)
Man(1) output converted with
man2html