[Bug 1011053] Rebooting takes a long time because dmeventd refuses to exit (LVM thin volume)
http://bugzilla.suse.com/show_bug.cgi?id=1011053
http://bugzilla.suse.com/show_bug.cgi?id=1011053#c6
zhen ren
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.
participants (1)
-
bugzilla_noreply@novell.com