DLM.CONF(5)

💖 DLM.CONF — bestie's guide to the dlm_controld config file 💖

okay so this is the manual for dlm.conf, aka the config file for dlm_controld. it's a section 5 page, so it lives in the "file formats" girlies section of your man pages. pull up a chair 🫶

---

✨ SYNOPSIS ✨

/etc/dlm/dlm.conf

like. that's the path. that's the whole vibe. 💅

---

🌸 DESCRIPTION 🌸

okay so the settings in dlm.conf mirror the dlm_controld command line options. same energy, different location. but bestie, plot twist: the config file also lets you do advanced fencing and lockspace configuration that the command line just cannot do. command line could never 💀

✨ Command line equivalents ✨

here's the tea: if an option shows up both on the command line and in the config file, the command line wins. it overrides the config file setting, no debate, no discussion, periodt. 👑

if you want the full descriptions of these, go read dlm_controld(8). if you want the defaults, run dlm_controld -h.

Format:

setting=value

Example:

log_debug=1
post_join_delay=10
protocol=tcp

Options:

• daemon_debug(*)
• log_debug(*)
• protocol
• mark
• debug_logfile(*)
• enable_plock
• plock_debug(*)
• plock_rate_limit(*)
• plock_ownership
• drop_resources_time(*)
• drop_resources_count(*)
• drop_resources_age(*)
• post_join_delay(*)
• enable_fencing
• enable_concurrent_fencing
• enable_startup_fencing
• enable_quorum_fencing(*)
• enable_quorum_lockspace(*)
• repeat_failed_fencing(*)
• enable_helper

the ones with (*) ** can be reloaded while stuff is running — see **Reload config down below 🔄

---

🔄 Reload config 🔄

some dlm.conf settings can be changed while dlm_controld is still running, using dlm_tool reload_config. not me being able to hot-swap my config, iconic honestly ✨

here's the routine, bestie:

1. edit dlm.conf — add stuff, remove stuff, comment stuff out, change values, whatever
2. run dlm_tool reload_config to apply those changes in dlm_controld
3. run dlm_tool dump_config to see the new settings

---

🛡️ Fencing 🛡️

okay this is the big one. a fence device definition begins with a device line, and then a bunch of connect lines follow — one for each node connected to the device. one connect per node, no skipping. 📋

a blank line separates device definitions. that's the divider between your lil fence blocks, okay?

devices are used in the order they are listed. order matters, don't shuffle. 🫶

the device key word is followed by:

• a unique dev_name
• the agent program to be used
• args, which are agent arguments specific to the device

the connect key word is followed by:

• the dev_name of the device section
• the node ID of the connected node, in the format node=nodeid
• args, which are agent arguments specific to the node for the given device

the format of args is key=val on both device and connect lines, with each pair separated by a space, e.g. key1=val1 key2=val2 key3=val3.

Format:

device  dev_name agent [args]
connect dev_name node=nodeid [args]
connect dev_name node=nodeid [args]
connect dev_name node=nodeid [args]

Example:

device  foo fence_foo ipaddr=1.1.1.1 login=x password=y
connect foo node=1 port=1
connect foo node=2 port=2
connect foo node=3 port=3

device  bar fence_bar ipaddr=2.2.2.2 login=x password=y
connect bar node=1 port=1
connect bar node=2 port=2
connect bar node=3 port=3

🎀 Parallel devices 🎀

some devices — think dual power, or dual path — must all be turned off in parallel for fencing to actually succeed. it's a group project where everyone has to participate or nobody gets credit 😭

to define multiple devices as parallel to each other, use the same base dev_name with different suffixes, and a colon separator between the base name and the suffix.

Format:

device  dev_name:1 agent [args]
connect dev_name:1 node=nodeid [args]
connect dev_name:1 node=nodeid [args]
connect dev_name:1 node=nodeid [args]

device  dev_name:2 agent [args]
connect dev_name:2 node=nodeid [args]
connect dev_name:2 node=nodeid [args]
connect dev_name:2 node=nodeid [args]

Example:

device  foo:1 fence_foo ipaddr=1.1.1.1 login=x password=y
connect foo:1 node=1 port=1
connect foo:2 node=2 port=2
connect foo:3 node=3 port=3

device  foo:2 fence_foo ipaddr=5.5.5.5 login=x password=y
connect foo:2 node=1 port=1
connect foo:2 node=2 port=2
connect foo:2 node=3 port=3

🦋 Unfencing 🦋

sometimes a node needs to "unfence" itself when it's starting up. the unfencing command reverses the effect of a previous fencing operation against it. like an undo button but for infrastructure 💫

an example would be fencing that disables a port on a SAN switch — a node could use unfencing to re-enable its switch port when starting up after rebooting.

⚠️ bestie, care must be taken to ensure it's safe for a node to unfence itself. a node often needs to be cleanly rebooted before unfencing itself. do not skip this, fr fr.

to specify that a node should unfence itself for a given device, the unfence line is added after the connect lines.

Format:

device  dev_name agent [args]
connect dev_name node=nodeid [args]
connect dev_name node=nodeid [args]
connect dev_name node=nodeid [args]
unfence dev_name

Example:

device  foo fence_foo ipaddr=1.1.1.1 login=x password=y
connect foo node=1 port=1
connect foo node=2 port=2
connect foo node=3 port=3
unfence foo

🧚 Simple devices 🧚

in some cases, a single fence device is used for all nodes, and it requires no node-specific args. this would typically be a "bridge" fence device, where an agent is passing a fence request to another subsystem to handle.

ngl, note that a node=nodeid arg is always automatically included in agent args, so a node-specific nodeid is always present to minimally identify the victim. so like, don't worry, the victim is always identifiable 💅

in such a case, a simplified, single-line fence configuration is possible, with format:

fence_all agent [args]

Example:

fence_all dlm_stonith

⚠️ a fence_all configuration is not compatible with a fence device configuration (above). pick a lane, bestie.

unfencing can optionally be applied with:

fence_all agent [args]
unfence_all

---

👑 Lockspace configuration 👑

a lockspace definition begins with a lockspace line, followed by a bunch of master lines. a blank line separates lockspace definitions.

Format:

lockspace ls_name [ls_args]
master    ls_name node=nodeid [node_args]
master    ls_name node=nodeid [node_args]
master    ls_name node=nodeid [node_args]

🌈 Disabling resource directory 🌈

lockspaces usually use a resource directory to keep track of which node is the master of each resource. but the dlm can operate without the resource directory by statically assigning the master of a resource using a hash of the resource name. to enable that, set the per-lockspace nodir option to 1.

Example:

lockspace foo nodir=1

💜 Lock-server configuration 💜

the nodir setting can be combined with node weights to create a configuration where select node(s) are the master of all resources/locks. these master nodes can be viewed as "lock servers" for the other nodes. main character nodes, honestly 👑

Example of nodeid 1 as master of all resources:

lockspace foo nodir=1
master    foo node=1

Example of nodeid's 1 and 2 as masters of all resources:

lockspace foo nodir=1
master    foo node=1
master    foo node=2

lock management will be partitioned among the available masters. there can be any number of masters defined. the designated master nodes will master all resources/locks (according to the resource name hash). when no masters are members of the lockspace, then the nodes revert to the common fully-distributed configuration. recovery is faster, with little disruption, when a non-master node joins/leaves. slay 🎀

there is no special mode in the dlm for this lock server configuration — it's just a natural consequence of combining the nodir option with node weights. when a lockspace has master nodes defined, the master has a default weight of 1 and all non-master nodes have weight of 0. an explicit non-zero weight can also be assigned to master nodes, e.g.

lockspace foo nodir=1
master    foo node=1 weight=2
master    foo node=2 weight=1

in which case node 1 will master 2/3 of the total resources and node 2 will master the other 1/3. math ate 💅

⭐ Node configuration ⭐

node configurations can be set by the node keyword followed of key-value pairs.

Keys:

• mark — the mark key can be used to set a specific mark value which is then used by the in-kernel DLM socket creation. this can be used to match for DLM specific packets for e.g. routing.

Example of setting a per socket value for nodeid 1 and a mark value of 42:

node id=1 mark=42

for local nodes this value doesn't have any effect. 🙈

---

🌟 SEE ALSO 🌟

• dlm_controld(8)
• dlm_tool(8)

---

and that's the whole page bestie!! this one came from the dlm crew and it's dated 2012-04-09 — yeah she's an elder but she still serves 🫶 go forth and configure responsibly, mwah 💖✨