LVM tools spawn dmeventd lazily when needed (i.e. when dmeventd isn't already running, or systemd-activated socket is not listening). The problem is dmeventd is spawned in daemon mode, and its daemonization routine tries to close all file descriptors up to RLIMIT_NOFILE, which takes minutes when limit is billions (e.g. 1073741816). Reproduction steps: 1) Not have dm-event.socket/dm-event.service enabled 2) Run some LVM command with large open file descriptor limit, e.g.: sudo sh -c 'ulimit -n 1073741816; lvcreate --size 15G --snapshot --name snap0 /dev/mapper/vg0-root' Although the reproduction case above has an explicit ulimit -n 1073741816 command, processes run in systemd service context typically have large open file limit by default. This is mostly an upstream issue, but it's partially caused by somewhat uncommon Gentoo policy of not enabling services when installing packages, and thus one is unlikely to encounter this problem on other distros. Workaround: enable either dm-event.socket or dm-event.service. Those start dmeventd in foreground (-f), bypassing this daemonization step.
There's really not much we can do about this. Our policy is to not enable services by default. As well, dmeventd is optional, and may be disabled via lvm.conf.
Fair enough. I opened the bug mainly to document the problem and its workarounds. (and I personally do like the policy of not enabling services by default)
Thanks for proposing https://gitlab.com/lvmteam/lvm2/-/merge_requests/6 upstream. It's a nice fix.
