Comment # 6 on bug 1011053 from zhen ren

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