---
name: "fence_node"
section: "8"
platform: "linux"
package: "cman"
version: "3.1.8-1.2+b1"
release: "Debian 8 (Jessie)"
platforms: ["linux"]
url: "https://new.carta.tech/fence_node"
---

# fence\_node(8)

a utility to run fence agents

## NAME

fence\_node - a utility to run fence agents

## SYNOPSIS

**fence\_node** \[OPTIONS\] *nodename*

## DESCRIPTION

This utility runs a fence agent against *nodename*. The agent and args are taken from the running cluster configuration based on [**cluster.conf**(5)](/cluster.conf/5.md).

**fence\_node** is a wrapper around the libfence functions: fence\_node() and unfence\_node(). These libfence functions use libccs to read the node fencing configuration, which means that corosync (with cman and ccs) must be running to use [**fence\_node**(8)](/fence_node/8.md).

The [**fenced**(8)](/fenced/8.md) daemon is the main user of libfence:fence\_node(), and the configuration details for that function are given in the [**fenced**(8)](/fenced/8.md) man page.

### Fencing vs. Unfencing

The main use for unfencing is with storage/SAN (non-power) agents.

When using power-based fencing agents, the fencing action itself is supposed to turn a node back on after first turning the power off (this happens automatically with a "reboot" action, and needs to be configured explicitly as "off" + "on" otherwise.)

When using storage-based fencing agents, the fencing action is not allowed to re-enable a node after disabling it.  Re-enabling a fenced node is only safe once the node has been rebooted.  A natural way to re-enable a fenced node's access to storage, is for that node to re-enable the access itself during its startup process.  The cman init script calls fence\_node -U (nodename defaults to local nodename when unfencing).  Unfencing a node without an \<unfence\> configuration (see below) is a no-op.

The basic differences between fencing and unfencing:

**Fencing**

- 1\.

  libfence: fence\_node(), command line: fence\_node nodename

- 2\.

  Turns off or disables a node.

- 3\.

  Agents run with the default action of "off", "disable" or "reboot".

- 4\.

  Performed by a cluster node against another node that fails (by the fenced daemon).

**Unfencing**

- 1\.

  libfence: unfence\_node(), command line: fence\_node -U nodename

- 2\.

  Turns on or enables a node.

- 3\.

  Agents run with the explicit action of "on" or "enable".

- 4\.

  Performed by a cluster node "against" itself during startup (by the cman init script).

## OPTIONS

- **-U**

  Unfence the node, default local node name.

- **-v**

  Show fence agent results, -vv to also show agent args.

- **-h**

  Print a help message describing available options, then exit.

- **-V**

  Print program version information, then exit.

## FILES

The Unfencing/unfence\_node() configuration is very similar to the Fencing/fence\_node() configuration shown in [**fenced**(8)](/fenced/8.md). Unfencing is only performed for a node with an \<unfence\> section:

```
<clusternode name="node1" nodeid="1">
        <fence>
        </fence>
        <unfence>
        </unfence>
</clusternode>
```

The \<unfence\> section does not contain \<method\> sections like the \<fence\> section does.  It contains \<device\> references directly, which mirror the corresponding device sections for \<fence\>, with the notable addition of the explicit action of "on" or "enable".  The same \<fencedevice\> is referenced by both fence and unfence \<device\> lines, and the same per-node args should be repeated.

```
<clusternode name="node1" nodeid="1">
        <fence>
        <method name="1">
        <device name="myswitch" foo="x"/>
        </method>
        </fence>
        <unfence>
        <device name="myswitch" foo="x" action="on"/>
        </unfence>
</clusternode>
```

## SEE ALSO

[**fenced**(8)](/fenced/8.md)