Mailinglist Archive: opensuse-bugs (4250 mails)

< Previous Next >
[Bug 1011053] Rebooting takes a long time because dmeventd refuses to exit (LVM thin volume)
  • From: bugzilla_noreply@xxxxxxxxxx
  • Date: Mon, 09 Jan 2017 10:01:09 +0000
  • Message-id: <bug-1011053-21960-rWbpRFla0B@http.bugzilla.suse.com/>
http://bugzilla.suse.com/show_bug.cgi?id=1011053
http://bugzilla.suse.com/show_bug.cgi?id=1011053#c6

zhen ren <zren@xxxxxxxx> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |thiago@xxxxxxx
Flags| |needinfo?(thiago@xxxxxxx)

--- Comment #6 from zhen ren <zren@xxxxxxxx> ---
Hi,

I can replicate this locally now;-)


I can confirm that the message "WARNING: There are still devices being
monitored." comes from dmeventd (the string is in the /usr/sbin/dmeventd
executable). I can confirm that the dmeventd process is running after boot.
And yet:

According to "man dmeventd", it will be started to run when
mirror/raid/snapshot/thin feature(s) is/are used. In your case, it's "thin
pool" - system-pool0-tpool being monitored. The time when we create/activate a
thin pool is good chance to start this deamon, which can be done within the
code of LVM tools' commands.

Enabling the "dm-event.service" explicitly works for me. Could you have a try?

Thanks again for your reporting!
Eric


$ systemctl status dm-event.socket dm-event.service
● dm-event.socket - Device-mapper event daemon FIFOs
Loaded: loaded (/usr/lib/systemd/system/dm-event.socket; disabled; vendor
preset: disabled)
Active: inactive (dead)
Docs: man:dmeventd(8)
Listen: /run/dmeventd-server (FIFO)
/run/dmeventd-client (FIFO)

● dm-event.service - Device-mapper event daemon
Loaded: loaded (/usr/lib/systemd/system/dm-event.service; disabled;
vendor preset: disabled)
Active: inactive (dead)
Docs: man:dmeventd(8)

In fact, it appears as part of D-Bus:
$ systemctl status `pidof dmeventd`
● dbus.service - D-Bus System Message Bus
Loaded: loaded (/usr/lib/systemd/system/dbus.service; static; vendor
preset: disabled)
Active: active (running) since sex 2016-11-18 10:54:19 PST; 1h 49min ago
Docs: man:dbus-daemon(1)
Main PID: 1526 (dbus-daemon)
Tasks: 4 (limit: 512)
CGroup: /system.slice/dbus.service
├─1526 /bin/dbus-daemon --system --address=systemd: --nofork
--nopidfile --systemd-activation
└─5211 /usr/sbin/dmeventd

I can't find anything that would explain why D-Bus would launch dmeventd. My
theory is that it's an indirect launch: something that D-Bus did launch, in
turn, launched dmeventd and exited. Most likely candidate: snapperd. I'll
confirm on my next boot if dmeventd is running right after boot, or if it
gets started after the first snapshot.

dmevent_tool says it's monitoring a thin pool:
# dmevent_tool -m
cr_nvme0n1p4 not monitored
system-home not monitored
Device Name: system-pool0-tpool
Registered DSO: libdevmapper-event-lvm2thin.so
UUID:
LVM-BamL3VFZvnwDfdhJkIfI8YdUqT38atmLZ5CoKIjkdR8wuJ6DtlS11a2hf4PZf3m5-tpool
Status: Active
Major Device #: 254
Minor Device #: 6
Read-only Device: No
Error Events: 0
system-pool0_tdata not monitored
system-pool0_tmeta not monitored
system-pool0 not monitored

/etc/lvm/lvm.conf has "monitoring = 1" and it's the default in the lvm2
package.

/dev/system/home is an LVM thin LV on the thin pool /dev/system/pool0.
Snapper is configured to snapshot it every hour
(https://lizards.opensuse.org/2012/07/25/snapper-lvm/).

# snapper -c home get-config
Key | Value
-----------------------+----------
ALLOW_GROUPS |
ALLOW_USERS |
BACKGROUND_COMPARISON | yes
EMPTY_PRE_POST_CLEANUP | yes
EMPTY_PRE_POST_MIN_AGE | 1800
FSTYPE | lvm(ext4)
NUMBER_CLEANUP | yes
NUMBER_LIMIT | 50
NUMBER_LIMIT_IMPORTANT | 10
NUMBER_MIN_AGE | 1800
QGROUP |
SPACE_LIMIT | 0.5
SUBVOLUME | /home
SYNC_ACL | yes
TIMELINE_CLEANUP | yes
TIMELINE_CREATE | yes
TIMELINE_LIMIT_DAILY | 10
TIMELINE_LIMIT_HOURLY | 10
TIMELINE_LIMIT_MONTHLY | 10
TIMELINE_LIMIT_WEEKLY | 0
TIMELINE_LIMIT_YEARLY | 10
TIMELINE_MIN_AGE | 1800

--
You are receiving this mail because:
You are on the CC list for the bug.
< Previous Next >