Description of problem:
I'm still trying to figure out what state or cmd exactly causes these. It appears many of the lvm cmds can result in these types messages.
[root@hayes-02 ~]# grep "Failed to parse status." /var/log/messages | wc -l
Version-Release number of selected component (if applicable):
kernel-4.18.0-48.el8 BUILT: Sat Dec 1 19:25:48 CST 2018
lvm2-2.03.01-1.el8 BUILT: Thu Nov 1 04:29:08 CDT 2018
lvm2-libs-2.03.01-1.el8 BUILT: Thu Nov 1 04:29:08 CDT 2018
lvm2-dbusd-2.03.01-1.el8 BUILT: Thu Nov 1 04:31:09 CDT 2018
lvm2-lockd-2.03.01-1.el8 BUILT: Thu Nov 1 04:29:08 CDT 2018
boom-boot-0.9-5.el8 BUILT: Wed Sep 19 16:56:59 CDT 2018
cmirror-2.03.01-1.el8 BUILT: Thu Nov 1 04:29:08 CDT 2018
device-mapper-1.02.153-1.el8 BUILT: Thu Nov 1 04:29:08 CDT 2018
device-mapper-libs-1.02.153-1.el8 BUILT: Thu Nov 1 04:29:08 CDT 2018
device-mapper-event-1.02.153-1.el8 BUILT: Thu Nov 1 04:29:08 CDT 2018
device-mapper-event-libs-1.02.153-1.el8 BUILT: Thu Nov 1 04:29:08 CDT 2018
device-mapper-persistent-data-0.7.6-1.el8 BUILT: Sun Aug 12 04:21:55 CDT 2018
Surely failure in parsing is bug and should not happen - so there is some status line of some dm target where lvm2 is not able to properly parse it - I can assume it's result of dmeventd monitoring.
So when you get the message logged - please attach also 'dmsetup table' & 'dmsetup status'.
I'd guess this could have been related with the change of dm cache status line fixed with this commit:
So closing - if there is still something like this - we would need to know exact cause.
As the reported message is important and needs fix in lvm2 code to enahance parser to understand new status information.
As the bug has been already fixed in several releases - closing as 'CURRENTRELEASE' with assumption such message are gone already for long time (fixed in 2019).