STONITH(8)

💅 stonith — bestie's guide to the STONITH(8) manual 💅

okay so you found the stonith man page and you're like "what is this, why is it screaming at me" — don't worry, i got you. it's a system administration utility, it's iconic, it's a little unhinged, and we're gonna go through it together. 🫶

---

✨ NAME ✨

stonith — an extensible interface for remotely powering down a node in the cluster. yes. that's the whole job. it's giving "just turn it off." 😌

---

🦋 SYNOPSIS 🦋

here's how you actually call it, no cap:

stonith -h

stonith [-s] [-h] -L

stonith [-s] [-h] -t stonith-device-type -n

stonith [-s] [-h] -t stonith-device-type {name=value...  |
        -p stonith-device-parameters | -E |
        -F stonith-device-parameters-file} [-c count] [-l] [-S]

stonith [-s] [-h] -t stonith-device-type {name=value...  |
        -p stonith-device-parameters | -E |
        -F stonith-device-parameters-file} [-c count]
        [-T {reset | on | off}] [nodename]

---

🌸 DESCRIPTION 🌸

so the STONITH module gives you an extensible interface for remotely powering down a node in the cluster. and what does STONITH stand for, you ask? Shoot The Other Node In The Head. 😭 yes fr fr, that's the actual acronym, they really said "let's name it after violence."

the idea is genuinely quite simple: when the software running on one machine wants to make sure another machine in the cluster is not using a resource, you just... pull the plug on the other machine. that's it. that's the strategy. 💀

it's simple and reliable — albeit admittedly brutal. the man page said it, not me. main character energy tbh. 👑

---

🎀 OPTIONS 🎀

the following options are supported, bestie. all of them. every single one. we don't skip. 💖

• -c count — performs any actions identified by the -l, -S and -T options count times. so like, do the thing that many times. 🔁
• -F stonith-device-parameters-file — the path of the file specifying parameters for a stonith device. to figure out the syntax of the parameters file for a given device type, run:

# stonith -t stonith-device-type -n

all of the listed parameters need to appear in order, on a single line in the parameters file, and be delimited by whitespace. order matters, bestie. ✨

• -E — reads the configuration from the environment. the environment variable names are the same as the parameter names. it's giving "no config file, just vibes." 🌈
• -h — displays detailed information about a stonith device, including description, configuration information, parameters, and any other related information. when specified without a stonith-device-type, detailed info on all stonith devices is displayed.

and if you don't yet own a stonith device and want to know more about the ones we support, this information is likely to be helpful. window shopping, but make it power management. 🛍️

• -L — lists the valid stonith device types, suitable for passing as an argument to the -t option. this is your menu, order up. 📋
• -l — lists the hosts controlled by the stonith device. 🖥️
• -n — outputs the parameter names of the stonith device. just the names, no values, we're being mysterious. 🙈
• name=value — a parameter, in the form of a name/value pair, to pass directly to the stonith device. to determine the syntax of the parameters for a given device type, run:

# stonith -t stonith-device-type -n

all of the listed parameter names need to be passed with their corresponding values. all of them. no skipping. 😤

• -p stonith-device-parameters — parameters to pass directly to the stonith device. to determine the syntax of the parameters for a given device type, run:

# stonith -t stonith-device-type -n

all of the listed parameter names need to appear in order and be delimited by whitespace. position is everything, literally. 🎯

• -S — shows the status of the stonith device. vibe check, but for hardware. ✅
• -s — silent operation. suppresses logging of error messages to standard error. shhh. 🤫
• -T action — the stonith action to perform on the node identified by nodename. chosen from reset, on, and off. three choices, all valid, pick your fighter. 🥊

Note — if a nodename is specified without the -T option, the stonith action defaults to reset.

• -t stonith-device-type — the type of the stonith device to be used to effect stonith. a list of supported devices for an installation may be obtained using the -L option. 👑
• -v — ignored. that's it. that's the whole description. it's there. it does nothing. iconic behaviour honestly. 💀

---

🔥 EXAMPLES 🔥

okay this is the fun part, let's actually do something.

to determine which stonith devices are available on your installation, use the -L option:

# stonith -L

all of the supported devices will be displayed one per line. choose one from this list that is best for your environment — let's use wti_nps for the rest of this example. to get detailed information about this device, use the -h option:

# stonith -t wti_nps -h

included in the output is the list of valid parameter names for wti_nps. to get just the list of valid parameter names, use the -n option instead:

# stonith -t wti_nps -n

all of the required parameter names will be displayed one per line. for wti_nps the output is:

ipaddr
password

there are three ways to pass these parameters to the device. the first (and preferred) way is by passing name/value pairs on the stonith command line:

# stonith -t wti_nps ipaddr=my-dev-ip password=my-dev-pw ...

the second way, which is maintained only for backward compatibility with legacy clusters, is passing the values in order on the stonith command line with the -p option:

# stonith -t wti_nps -p "my-dev-ip my-dev-pw" ...

the third way, which is also maintained only for backward compatibility with legacy clusters, is placing the values in order on a single line in a config file:

my-dev-ip my-dev-pw

... and passing the name of the file on the stonith command line with the -F option:

# stonith -t wti_nps -F ~/my-wtinps-config ...

to make sure you have the configuration set up correctly and that the device is available for stonith operations, use the -S option:

# stonith -t wti_nps ipaddr=my-dev-ip password=my-dev-pw -S

if all is well at this point, you should see something similar to:

stonith: wti_nps device OK.

if you don't, some debugging may be necessary to determine if the config info is correct, the device is powered on, etc. the -d option can come in handy here — you can add it to any stonith command to cause it to generate debug output. 🔍

to get the list of hosts controlled by the device, use the -l option:

# stonith -t wti_nps ipaddr=my-dev-ip password=my-dev-pw -l

all of the hosts controlled by the device will be displayed one per line. for wti_nps the output could be:

node1
    node2
    node3

to power off one of these hosts, use the -T option:

# stonith -t wti_nps ipaddr=my-dev-ip password=my-dev-pw -T off node

and that's how you politely (?) turn a machine off from very far away. 💅

---

💜 SEE ALSO 💜

go read these next, bestie, they're part of the lore:

• heartbeat(8)
• meatclient(8)

---

👑 AUTHORS 👑

the legends who made this happen:

• Alan Robertson <alanr@unix.sh>
  • stonith
• Simon Horman <horms@vergenet.net>
  • man page
• Florian Haas <florian.haas@linbit.com>
  • man page

---

and that's the whole page, no notes. this was cluster-glue 1.0.12, dated December 7, 2009 — an absolute classic, still slaying after all these years. go forth and power down responsibly. 🦋✨💖