Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1443392

Summary: lvm2 update takes a long time
Product: Red Hat Enterprise Linux 7 Reporter: Marko Myllynen <myllynen>
Component: lvm2Assignee: Marian Csontos <mcsontos>
lvm2 sub component: LVM Metadata / lvmetad QA Contact: cluster-qe <cluster-qe>
Status: CLOSED INSUFFICIENT_DATA Docs Contact:
Severity: unspecified    
Priority: unspecified CC: agk, heinzm, jbrassow, mcsontos, msnitzer, myllynen, prajnoha, redhat-bugzilla, teigland, zkabelac
Version: 7.3   
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-03-25 14:54:25 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Marko Myllynen 2017-04-19 07:38:36 UTC
Description of problem:
At least since the latest lvm2 update (lvm2-2.02.166-1.el7_3.4.x86_64) Yum spends a long time (~90 seconds) in the clean up phase of lvm2; pstree(1) shows a postscript is executing "systemctl try-restart lvm2-lvmetad.service". This has been observed on some machines, and even on them sporadically, doing "systemctl try-restart lvm2-lvmetad.service" afterwards may get stuck once but then work ok later on.

Apr 19 10:00:01 localhost systemd: Stopping LVM2 metadata daemon...
Apr 19 10:00:01 localhost lvmetad[569]: Failed to accept connection errno 11.
Apr 19 10:01:31 localhost systemd: lvm2-lvmetad.service stop-sigterm timed out. Killing.
Apr 19 10:01:31 localhost systemd: lvm2-lvmetad.service: main process exited, code=killed, status=9/KILL
Apr 19 10:01:31 localhost systemd: Unit lvm2-lvmetad.service entered failed state.
Apr 19 10:01:31 localhost systemd: lvm2-lvmetad.service failed.
Apr 19 10:01:31 localhost systemd: Started LVM2 metadata daemon.
Apr 19 10:01:31 localhost systemd: Starting LVM2 metadata daemon...
Apr 19 10:01:31 localhost systemd: Reloading.

Please try to make the "systemctl try-restart lvm2-lvmetad.service" operation faster in all cases.

Version-Release number of selected component (if applicable):
lvm2-2.02.166-1.el7_3.4.x86_64

Comment 2 Marian Csontos 2017-04-19 19:03:16 UTC
It is reproducible. This seems the problem:

> Apr 19 10:00:01 localhost lvmetad[569]: Failed to accept connection errno 11.

Comment 3 David Teigland 2017-04-19 19:16:19 UTC
Similar issue was dealt with here

https://sourceware.org/git/?p=lvm2.git;a=commitdiff;h=b12961e7ebd6fb29d760daafd3c16e4ba3e54e80

An lvmetad core or lvmetad gdb backtrace would probably help.

Comment 4 Marko Myllynen 2017-04-20 08:12:57 UTC
I tried to reproduce this by downgrading lvm2/device-mapper packages on few machines where I saw this and then upgrading again but the issue did not occur.

Currently I am unable to provide more information.

Thanks.

Comment 5 Jonathan Earl Brassow 2017-04-26 16:03:55 UTC
(In reply to Marian Csontos from comment #2)
> It is reproducible. This seems the problem:
> 
> > Apr 19 10:00:01 localhost lvmetad[569]: Failed to accept connection errno 11.

Marian, if you can reproduce, can you provide the info dave is looking for?

Comment 6 Marian Csontos 2017-04-27 15:47:22 UTC
"Reproducible" is not the right word. "Common" would be better. Second attempt to try-restart was executed immediately. If seen again I will try to get more details.

Comment 7 Marian Csontos 2019-03-25 14:54:25 UTC
No data collected in two years. Closing this...