Check and Control lvmpolld with systemd

lvmpolld is the daemon that keeps one background poller running instead of a separate one per LVM operation. This guide checks it, inspects its systemd units, and dumps its state when it is running. It covers the installed Ubuntu package, lvm2 2.03.16-3ubuntu3.2, whose daemon reports version 2.03.16(2) (2022-05-18).

Time: about fifteen minutes.
Privileges: most checks are read-only; starting the service changes host state and needs root.

1. Confirm the installed daemon

Start with ordinary, read-only commands. They show which executable is being used and the option set that belongs to this installation:

$ command -v lvmpolld
/usr/sbin/lvmpolld
$ lvmpolld --version
lvmpolld version: 2.03.16(2) (2022-05-18)
$ lvmpolld --help
Usage:
lvmpolld [-V] [-h] [-f] [-l {all|wire|debug}] [-s path] [-B path] [-p path] [-t secs]
lvmpolld --dump [-s path]

The daemon is not a general-purpose LVM command. LVM submits polling work to it after operations such as lvconvert, pvmove, lvchange or vgchange have started, so its job is to keep one polling daemon and avoid a separate background polling process for each operation.

2. Check whether LVM is configured to use it

The global/use_lvmpolld setting controls whether LVM uses the daemon. Ask LVM for its effective default configuration rather than guessing from a commented file:

$ lvmconfig --type default global/use_lvmpolld
# use_lvmpolld=1

On this machine the effective default is enabled. The command does not prove a daemon is currently running; it only answers whether LVM is allowed to use the lvmpolld path, and the setting only applies when LVM was built with lvmpolld support.

Checkpoint: if your output shows # use_lvmpolld=0, investigate the LVM configuration before troubleshooting the daemon. Do not edit /etc/lvm/lvm.conf just to make a status check pass.

3. Inspect the socket-activated unit

On this installation systemd provides lvm2-lvmpolld.socket and lvm2-lvmpolld.service. The socket listens at /run/lvm/lvmpolld.socket; the service runs lvmpolld -t 60 -f and uses /run/lvmpolld.pid. Inspect both units without changing them:

$ systemctl is-enabled lvm2-lvmpolld.socket
$ systemctl is-active lvm2-lvmpolld.socket
$ systemctl is-active lvm2-lvmpolld.service

Blank output or a non-zero status is still useful: it can mean a unit is not installed or not enabled. For a fuller explanation, run systemctl status lvm2-lvmpolld.socket lvm2-lvmpolld.service. A socket can be listening while the service is inactive, because systemd may only start the service when a client connects.

Tip: do not confuse the two paths. /run/lvmpolld.pid prevents duplicate daemon instances, while /run/lvm/lvmpolld.socket is the communication endpoint. Removing either file while a daemon or socket unit is active can make the next request fail, and there is no reason to delete them during normal diagnosis.

4. Start it only when the host needs it

If the socket is installed but inactive, starting it is an administrative action that can affect later LVM operations, so check the host's maintenance window first:

$ sudo systemctl start lvm2-lvmpolld.socket
$ systemctl is-active lvm2-lvmpolld.socket
active

Socket activation normally starts the service when a request arrives. If you need to start the service explicitly, use the packaged unit rather than inventing paths or flags:

$ sudo systemctl start lvm2-lvmpolld.service
$ systemctl is-active lvm2-lvmpolld.service
active

Recovery: sudo systemctl stop lvm2-lvmpolld.service stops the daemon, and sudo systemctl stop lvm2-lvmpolld.socket stops new socket activation. Stopping it can interrupt LVM polling, so do not use those commands as a casual cleanup step, and do not treat a service restart as a substitute for finding a bad pidfile, socket permission or configuration problem.

5. Dump the daemon state

--dump contacts a running daemon and prints its complete state in a raw format. It is a diagnostic request, not a configuration export:

$ lvmpolld --dump

The output depends on the operations currently being polled, so an empty or short dump is possible when the daemon is idle. If the default socket is not usable, specify it explicitly:

$ lvmpolld --dump --socket /run/lvm/lvmpolld.socket

Permission errors mean your user cannot access the socket; they do not prove lvmpolld is broken. Repeat the read-only diagnostic with elevated privileges only if your local policy permits it:

$ sudo lvmpolld --dump --socket /run/lvm/lvmpolld.socket

Do not parse the raw dump as a stable API. Use it to see whether the daemon knows about an operation, then use the originating LVM command and system logs for the authoritative operational result.

Common traps

Reusing production paths for a manual test. The daemon accepts --foreground, custom --pidfile, custom --socket, and an idle --timeout, but those are for an isolated test, not a second production configuration. Reusing /run/lvmpolld.pid or /run/lvm/lvmpolld.socket can collide with the packaged instance; the manual specifically says to change both paths in a test environment.
Testing without a private directory. If you do test in a controlled environment, use a private directory and an explicit timeout, and run as the account that owns that directory:
```
$ test_dir="$(mktemp -d /tmp/lvmpolld-test.XXXXXX)"
$ lvmpolld --foreground --pidfile "$test_dir/lvmpolld.pid" \
    --socket "$test_dir/lvmpolld.socket" --timeout 5
```
Stop if the binary reports a permission or already-running error. This foreground process is expected to occupy the terminal until it becomes idle or you interrupt it; it is not connected to the systemd socket.
Cleaning up the wrong directory. Remove the private directory with rm -rf -- "$test_dir" only after the process has exited and you have confirmed the path is the temporary directory you created. Never substitute /run, /etc/lvm or another shared path.

Done means

Recorded the installed lvmpolld version and effective use_lvmpolld setting.
Inspected the systemd socket and service separately, understanding their pidfile and socket paths.
Used --dump only against a running daemon, and treated its raw output as diagnostic.
Kept any start or stop action deliberate, elevated and reversible.
Ran manual tests with separate pidfile and socket paths under a private temporary directory.