CONF(5)
π CONF(5) β LAM node process schema π
ok so bestie, welcome to conf(5) from the LAM FILE FORMATS corner of the manual. this one's niche, but we're gonna make it cute. π
β¨ NAME β¨
conf β LAM node process schema
πΈ DESCRIPTION πΈ
okay so real talk first: most LAM/MPI users can fully disregard this page. it's not for you, and that's fine. no shade. π
A process schema is basically a little list of the system processes that are gonna make up the LAM environment on one particular node. So it's the blueprint of who shows up to the party on that machine. π«Ά
LAM developers tho? they're obsessed with process schemata, because they're genuinely so useful for debugging and for generating custom systems. main character tool fr.
Separate default configuration files are normally used for booting either the single-daemon version (conf.lam) or the external-servers version (conf.otb). The single-daemon version is the default β that's the one you get unless you say otherwise. The external-servers version is typically what LAM developers reach for when they're debugging LAM services. π
The -c option to hboot(1) lets you specify the file name of a custom process schema. And heads up: this capability is not available with lamboot(1). so don't try it there, bestie.
Application programs can be booted with the LAM environment by including the program name in the process schema. yes, you can just... put it in there. iconic. β¨
π¦ STRUCTURE AND SYNTAX π¦
The process schema grammar defines three types of statements: comments, processes, and options. three flavors, one vibe check. π
Comments begin with # and terminate with a newline. short and sweet.
Process statements consist of a filename, command line arguments, and possibly options local to the process. The command line arguments are passed to the process when it is started. The process options are used by the booting tools before starting the process. (so like, args = for the process, options = for the booting tools. two different audiences. iykyk.)
Filenames may include application programs and any of the system processes listed below. here's the whole squad: π
bforwardβ bufferd helper, forwards remote messages.bufferdβ creates, kills, sweeps, and states buffers.dli_inetβ sends data on network connections.dlo_inetβ receives data from network connections.echodβ echoes messages; can be used to test nodes and links.filedβ serves file access.flatdβ provides symbolic access to node memory.iodβ handles stdio data of processes.kenyadβ controls and monitors processes.kernelβ coordinates message passing.lamdβ single-daemon version of all servers excludingleddandmtvd.leddβ controls LEDs.loaddβ loads executable files onto nodes.mtvdβ controls a pixel map display.routerβ maintains routing tables.tracedβ collects and transports trace data.
β οΈ Processes are started in the order given in the process schema, and for LAM, the order is important. The kernel must be first. like, no negotiating. kernel first or it's over. π
Process options are placed inside braces {} following the command line arguments. Process options consist of a keyword followed by an assigned value in parentheses. Options that are not explicitly given have default settings.
Here's the tea on scoping:
- Options inside braces in process statements apply only to that process.
- Options outside process statements apply to all processes that appear later in the process schema, unless locally overridden. (global girlies, but local can always overrule them. π )
All the options are listed below:
inet_topoβ a string ofdli_inetorlamdoptions, global only, default nullrtr_topoβ a string ofrouteroptions, global only, default nulldelayβ waiting time in seconds after process boot, default 0
The inet_topo and rtr_topo options can be overridden from the command line of hboot(1) using the -I and -R options respectively. π
π₯ EXAMPLES π₯
Following are example process schemata. The first file is used for an OTB node in LAM:
##
## typical LAM process schemata
##
lamd $inet_topo
The second file is used by LAM developers to control each server as an independent process, typically during debugging:
##
## external-servers LAM process schemata
##
##
## The kernel is listed first.
##
kernel $delay
##
## daemons
##
router
kenyad
dli_inet $inet_topo
dlo_inet
bufferd
bforward
loadd
echod
flatd
filed
traced
iod
see how kernel is sitting right at the top? exactly as the rules demand. periodt. π
π FILES π
$LAMHOME/etc/lam-conf.lamdβ default LAM node process schema, where$LAMHOMEis the installation directory$LAMHOME/etc/lam-conf.separateβ example external-servers node process schema used when debugging LAM
π SEE ALSO π
ok that's the whole page, bestie!! this one's from LAM 7.1.4, dated July, 2007 β so like, vintage, but make it slay. π β¨ go forth and schema responsibly, and remember: kernel goes first. always. π«Άπ
π¦ where this page comes from
- debian bookworm: lam-runtime 7.1.4-7+b1
- debian trixie: lam-runtime 7.1.4-7.2
- ubuntu jammy: lam-runtime 7.1.4-7
- ubuntu noble: lam-runtime 7.1.4-7.1build2
- ubuntu questing: lam-runtime 7.1.4-8
- ubuntu resolute: lam-runtime 7.1.4-8build1
- ubuntu stonking: lam-runtime 7.1.4-8build1
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms