DMEVENTD(8)

📦
version 2.03.44 · 14 versions
, in arch rolling

💖 DMEVENTD — the device-mapper event daemon, bestie edition 💖

okay so real talk: this is the manual page for dmeventd, which lives in section 8 of the system manager's manual (that's the "admin commands" shelf, iykyk). she's the Device-mapper event daemon, and she's honestly carrying the whole house on her back. let's get into it 🫶

✨ NAME ✨

dmeventd — the Device-mapper event daemon. that's her. that's the girl. 👑

✨ SYNOPSIS ✨

dmeventd [-d [-d [-d]]] [-e exit_on_path] [-f] [-g seconds] [-h] [-i]
         [-l] [-R] [-V] [-?]

like, that's a lot of little flags but don't panic, we're going through every single one and you're gonna know them all by the end, fr fr 💅

✨ DESCRIPTION ✨

so dmeventd is the event monitoring daemon for device-mapper devices. she just sits there, watching, keeping tabs on vibes. meanwhile, library plugins can register themselves with her and then carry out actions that get triggered whenever particular events pop off. it's giving group chat moderator energy, honestly. 🦋

✨ OPTIONS ✨

okay bestie, pop the corn, this is the long part. every single one, no skips:

  • -d — repeat this bad boy from 1 to 3 times (-d, -dd, -ddd) and the detail of the debug messages sent to syslog goes up. every extra d stacks on more debugging information. more d's = more lore. 🔍
  • -e exit_on_path — hand her a file path. when the daemon catches a signal (SIGINT, SIGTERM), the presence of this file is what lets her exit even though there are still monitored devices hanging around. this is a whole lifesaver during system shutdown, when devices haven't been unmonitored properly and she'd otherwise be stuck. want to disable this behaviour? set it to the empty string "". the default value is "/run/nologin". 🚪
  • -f — don't fork, run in the foreground. no background sneaky business, we're doing this in person. 👀
  • -g seconds — set the grace period for monitoring thread cleanup, and the range is 0-300 seconds, with a default of 10. during this window, monitoring threads that already finished processing events will wait around for potential reuse instead of immediately terminating (rude to just leave, honestly). if the same device and plugin combination gets registered again inside the grace period, the existing thread gets reused, which significantly reduces overhead. set it to 0 to disable thread reuse entirely. ♻️
  • -h — show help information. she's helpful like that. 🎀
  • -i — query the running daemon instance for status info. important heads up though: the format is internal and unstable and it's targeted for developers. the format may change between versions — so do NOT build your whole life on it, bestie. 💀
  • -l — log through stdout and stderr instead of syslog. this one works only with the -f option; otherwise it's just ignored. so like, they're a package deal. 🤝
  • -? — show help information on stderr. (same energy, different stream ✨)
  • -R — replace a running dmeventd instance. the running dmeventd must be version 2.02.77 or newer — no cap, that's the requirement. the new dmeventd instance will obtain a list of devices and events to monitor from the currently running daemon. passing the aux cord, basically. 🎧
  • -V — show version of dmeventd. simple, iconic. ⭐

✨ LVM PLUGINS ✨

these are the plugins that show up to the party. each one does its own little thing:

  • Mirror — attempts to handle device failure automatically. see lvm.conf(5). 🪞
  • Raid — attempts to handle device failure automatically. see lvm.conf(5). (yes, same energy as Mirror, they're siblings) 🛡️
  • Snapshot — monitors how full a snapshot is becoming and emits a warning to syslog when it exceeds 80% full. the warning gets repeated when 85%, 90% and 95% of the snapshot is filled. see lvm.conf(5). ⚠️ and here's the scary part: a snapshot that runs out of space becomes invalid, and when it is mounted, it is unmounted if possible. so like, keep an eye on that fullness percentage, bestie, seriously. 😭
  • Thin — monitors how full the thin pool's data and metadata are becoming and emits a warning to syslog when either exceeds 80% full. the warning repeats when more than 85%, 90% and 95% of the thin pool is filled. see lvm.conf(5). when a thin pool fills over 50% (data or metadata), the thin plugin calls the configured dmeventd/thin_command with every 5% increase. with the default setting it calls internal lvm lvextend --use-policies to resize the thin pool when it exceeds the configured threshold activation/thin_pool_autoextend_threshold. if the command fails, the dmeventd thin plugin will keep retrying execution with an increasing time delay between retries, up to 42 minutes (persistent queen 💅). you can also configure an external command for more advanced maintenance operations of a thin pool — for example, the external command can remove unneeded snapshots, use fstrim(8) to recover free space in a thin pool, or use lvextend --use-policies if other actions haven't released enough space. the command is executed with the environment variable LVM_RUN_BY_DMEVENTD=1 so any lvm2 command executed in this environment will not try to interact with dmeventd. to see the fullness of a thin pool, the command may check these two environment variables: DMEVENTD_THIN_POOL_DATA and DMEVENTD_THIN_POOL_METADATA. the command can also read status with tools like lvs(8). 🌸
  • Vdo — monitors how full a VDO pool's data is becoming and emits a warning to syslog when it exceeds 80% full. the warning repeats when more than 85%, 90% and 95% of the VDO pool is filled. see lvm.conf(5). when a VDO pool fills over 50%, the vdo plugin calls the configured dmeventd/vdo_command with every 5% increase. with the default setting it calls internal lvm lvextend --use-policies to resize the VDO pool when it exceeds the configured threshold activation/vdo_pool_autoextend_threshold. if the command fails, the dmeventd vdo plugin will keep retrying execution with an increasing time delay between retries, up to 42 minutes. you may also configure an external command for more advanced maintenance operations of a VDO pool — for example, the external command can free up unused space with fstrim(8), or use lvextend --use-policies if other actions haven't released enough space. the command is executed with the environment variable LVM_RUN_BY_DMEVENTD=1 so any lvm2 command executed in this environment will not try to interact with dmeventd. to see the fullness of a VDO pool, the command may check the DMEVENTD_VDO_POOL environment variable. the command can also read status with tools like lvs(8). 🧚

✨ ENVIRONMENT VARIABLES ✨

the env vars, the little messengers. here's who sets what:

  • DMEVENTD_THIN_POOL_DATA — variable is set by the thin plugin and is available to the executed program. the value represents actual usage of thin pool data volume. heads up: the variable is not set when an error event is processed. 🍓
  • DMEVENTD_THIN_POOL_METADATA — variable is set by the thin plugin and is available to the executed program. the value represents actual usage of thin pool metadata volume. and again: not set when an error event is processed. 🍓
  • DMEVENTD_VDO_POOL — variable is set by the vdo plugin and is available to the executed program. the value represents actual usage of VDO pool data volume. yep, you guessed it: not set when an error event is processed. 🍓
  • LVM_RUN_BY_DMEVENTD — variable is set by the thin and vdo plugins to prohibit recursive interaction with dmeventd by any lvm2 command run from a thin_command or vdo_command environment. protect the loop, protect the peace. 🌀

✨ SEE ALSO ✨

go read these next, they're all in the family:

lowkey a reminder: -i output is internal and unstable, and that snapshot running out of space becoming invalid is not a vibe. check your pools, bestie. 🫶

and that's the whole page!! brought to you by Red Hat, Inc., from DM TOOLS 2.03.44(2), dated 2026-10-27. 💖✨🎀 that's it, that's the manual, you ate, go monitor some devices, mwah 💅🌈

📦 where this page comes from