RECON(1)

🎀 recon(1) 🎀 — the LAM vibe check

okay bestie, welcome to RECON, straight outta the LAM TOOLS section 1 lineup 💅 this is the little tool you run before you try to start LAM, so you can find out if it's even gonna work. think of it as a pre-flight check, but make it fashion. ✨

---

🌸 NAME 🌸

recon — check if LAM can be started. that's it, that's the whole job. 💖

---

🦋 SYNOPSIS 🦋

recon [-a] [-b] [-d] [-h] [-v] [-nn] [-np] [-ssi key value] [bhost]

---

✨ OPTIONS ✨

• -a — report all the host errors. like, don't stop at the first oopsie, keep going and tell me everything 🙈
• -b — assume the local shell and the remote shell are the same thing. this means only one remote shell invocation is used to each node. if you don't use -b, then two remote shell invocations are used to each node. no cap.
• -d — turn on debugging. we're getting in the weeds, bestie 🔍
• -h — print the command help menu. classic.
• -ssi key value — send arguments to the various SSI modules. go read the SSI section below for the whole tea 🍵
• -v — be verbose. tell me everything as it happens, main character energy only 👑
• -nn — don't add "-n" to the remote agent command line
• -np — do not force the execution of $HOME/.profile on remote hosts

---

💜 DESCRIPTION 💜

so for LAM to actually get started on a remote UNIX machine, a few things have to line up. like, requirements. the vibe must be immaculate. there are four of them:

1. the machine has to be reachable via the network. basic networking slay.
2. the user has to be able to remotely execute on the machine using the default remote shell program that was chosen when LAM was configured. this is usually rsh(1), but literally any remote shell program is acceptable (like ssh(1), etc.). ⚠️ note that remote host permission must be configured such that the remote shell program will not ask for a password when a command is invoked on the remote host. no password prompts, periodt.
3. the remote user's shell must have a search path that will locate LAM executables. it's gotta find them.
4. the remote shell's startup file must not print anything to standard error when invoked non-interactively. like, silence please, we're working 🧚

if any of these requirements isn't met for any machine declared in bhost, LAM will not be able to start. that's the tea. so by running recon first, you get to quickly identify and correct the problems in your setup that would otherwise inhibit LAM from starting. proactive queen behavior 💅

the local machine where recon is invoked must be one of the machines specified in bhost.

the bhost file is a LAM boot schema written in the host file syntax. see bhost(5). instead of passing it on the command line, you can specify a boot schema 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/. 🫶

so here's the actual move: recon tests each machine defined in bhost by attempting to execute the tkill(1) command on it using its "pretend" option (no action is taken — it's just pretending, it's giving theater kid 🎭). this test, if it succeeds, indicates that all the requirements listed above are met, and therefore LAM can be started on the machine. if the attempt is successful, the next machine gets checked. if the attempt fails, a descriptive error message is displayed and recon stops — unless the -a option is used, in which case recon keeps on checking the remaining machines. resilient icon behavior.

if recon takes a long time to finish successfully, that's a good indication to the user that the LAM system to be started has slow communication links or heavily loaded machines, and it might be preferable to exclude or replace some of the machines in the system. like, lowkey a red flag 🚩

🍓 SSI (System Services Interface) 🍓

the -ssi switch lets you pass parameters to various SSI modules. LAM's SSI modules are described in detail in lamssi(7). SSI modules have direct impact on MPI programs because they allow tunable parameters to be set at run time (such as which boot device driver to use, what parameters to pass to that driver, etc.). tuneable, we love to see it.

the -ssi switch takes two arguments: key and value. the key argument generally specifies which SSI module will receive the value. for example, the key "boot" is used to select which RPI is used for starting processes on remote nodes. the value argument is the value that's passed. for example:

recon -ssi boot tm

tells LAM to use the "tm" boot module for native launching in PBSPro / OpenPBS environments (the tm boot module does not require a boot schema). convenient!

recon -ssi boot rsh -ssi rsh_agent "ssh -x" boot_file

tells LAM to use the "rsh" boot module, and tells the rsh module to use "ssh -x" as the specific agent to launch executables on remote nodes. obsessed. 🔥

and so on. LAM's boot SSI modules are described in lamssi_boot(7). this page should be consulted for specific actions that are taken by, and how to tweak the run-time behavior of, each boot module. iykyk.

the -ssi switch can be used multiple times to specify different key and/or value arguments. if the same key is specified more than once, the values are concatenated with a comma (",") separating them. stack 'em up bestie 🌈

note that the -ssi switch is simply a shortcut for setting environment variables. the same effect may be accomplished by setting corresponding environment variables before running lamboot. the form of the environment variables that LAM sets is: LAM_MPI_SSI_key=value.

note that the -ssi switch overrides any previously set environment variables. also note that unknown key arguments are still set as environment variables — they are not checked (by lamwipe) for correctness. illegal or incorrect value arguments may or may not be reported — it depends on the specific SSI module. so like, no promises on the error messages, it's giving "depends on the module" 💀

🌈 Remote Executable Invocation 🌈

all the tweakable aspects of launching executables on remote nodes during recon are discussed in lamssi(7) and lamssi_boot(7). topics include (but are not limited to): discovery of remote shell, run-time overrides of the agent used to launch remote executables (e.g., rsh and ssh), etc. go read those if you want the deep lore 📚

---

🌟 FILES 🌟

• laminstalldir/etc/lam-bhost.def — default boot schema file, where "laminstalldir" is the directory where LAM/MPI was installed.

---

⭐ EXAMPLES ⭐

recon -v mynodes

check if LAM can be started on all the UNIX machines described in the boot schema mynodes. report about important steps as they are done. narrated, as it should be 🎀

recon -v -a

check if LAM can be started on all the UNIX machines described in the default boot schema. report about important steps as they are done. check all the machines; do not stop after the first error message. thorough queen behavior, no notes 👑

---

💫 SEE ALSO 💫

rsh(1), tkill(1), bhost(5), lamboot(1), lamwipe(1), lam-helpfile(5), lamssi(7), lamssi_boot(7)

---

and that's the whole page bestie 🫶 this was LAM 7.1.4, from July, 2007 — yeah she's a vintage queen but she still slays 💅✨ bye!!