LAMSHRINK(1)
π lamshrink β bestie edition β¨
okay so welcome to lamshrink(1), a page from the LAM COMMANDS manual set, and it is literally the "we're downsizing the group chat" command. sit down, grab a strawberry π, and let's shrink a universe together.
πΈ NAME πΈ
lamshrink β shrink a LAM universe. yes bestie, an entire universe. and we're making it smaller. main character energy fr fr π
β¨ SYNOPSIS β¨
lamshrink [-dhv] [-w delay] nodeid
that's it. that's the whole vibe. one node, a couple of flags, and we're out π¦
π OPTIONS π
-dβ spill the tea in full detail. prints detailed debugging information.-hβ print useful information on this command. the classic "help me help you" flag π«Ά-vβ be verbose. say more words. we love a yapper.-w delayβ notify processes on the doomed node and pause for delay seconds before proceeding. a lil heads-up text before the block button πnodeidβ remove the LAM node with this ID. bye boo π
π DESCRIPTION π
so here's the situation. you've got an existing LAM session β initiated by lamboot(1) β and you can shrink it to include less nodes with lamshrink. one node is removed for each invocation, so it's very much a one-at-a-time situation, no bulk unfollowing here π. at a minimum, the node ID is given on the command line. and once lamshrink completes, that node ID is invalid across the remaining nodes β you can literally watch it happen by running lamnodes(1). gone. ghosted. not in the group chat anymore π
Existing application processes on the target node can be warned of impending shutdown with the -w option. a LAM signal (SIGFUSE) will be sent to these processes, and then lamshrink will pause for the given number of seconds before proceeding with removing the node. by default, SIGFUSE is ignored. you can install a different handler with ksignal(2) if you're feeling fancy β¨
All application processes on all remaining nodes are always informed of the death of a node. no secrets in this friend group. this is also done with a signal (SIGSHRINK), which by default causes a process's runtime route cache to be flushed (to remove any cached information on the dead node). π§Ή
okay listen closely bestie because this one matters: if this signal is re-vectored for the purpose of fault tolerance, the old handler should be called at the beginning of the new handler. don't skip that step. i'm serious. π
The signal does not, by itself, give the process information on which node has been removed. so how do you find out? one technique for getting this information is to query the router for information on all relevant nodes using getroute(2). the dead node will cause this routine to return an error. so like, the error is the answer. iconic honestly.
π FAULT TOLERANCE π
If enabled with lamboot(1), LAM will watch for nodes that fail. and here's the kicker β the procedure for removing a node that has failed is the same as lamshrink after the warning step. in particular, the SIGSHRINK signal is delivered. so failed node, shrunk node, same energy, same signal. slay π₯
π§ EXAMPLES π§
remove LAM on n1, and report about important steps as they are done:
lamshrink -v n1
inform all processes on LAM node 30 that the node will be dead in 10 seconds, wait 10 seconds, and remove the node β operating silently:
lamshrink n30 -w 10
see how it's giving "quiet quitting but for infrastructure" π
β SEE ALSO β
lamboot(1), lamnodes(1), ksignal(2), getroute(2)
and that's the page!! you're a LAM universe-shrinking icon now, no cap π
LAM 7.1.4 Β· July, 2007 β mwah, sending you off with this little dated-but-timeless manual-page moment ππ bye bestie, go shrink something (responsibly) π¦
π¦ 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