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.
DescriptionSteven J. Levine
2011-11-03 18:22:07 UTC
Some of the information in this article is covered in RHEL 6, perhaps enough, but I'm cloning this bug as a placeholder to check whether there's any info in the article that we should also add to the RHEL 6 documentation.
+++ This bug was initially created as a clone of Bug #712392 +++
Need to integrate the kbase article "How do I gather GFS lockdump information from RHEL 5 to send to Red Hat Support?" into official product docs.
Link to kbase article: https://access.redhat.com/kb/docs/DOC-19449
--- Additional comment from swhiteho on 2011-07-04 06:57:07 EDT ---
Some notes:
1. for RHEL6 and up, the gfs2_tool gettune command should be replaced with checking the data in /proc/mounts which is much less likely to get stuck if the system is in an odd state, and also is a much better source for such information.
2. If the GFS2 hangalyzer doesn't work, the lock dumps can be obtained manually by using the debugfs file directly. It should be noted as well that using large buffer size in this operation will speed it up considerably when large numbers of glocks are involved, so using dd to copy the information is a much better solution, since bs can be set to something suitably large (e.g. 4M).
Otherwise the info looks good to me.
--- Additional comment from slevine on 2011-11-01 15:15:54 EDT ---
This is an issue for the GFS manual, so it should have been assigned to me. This is the first I'm seeing it, though, and it's past the end of the 5.8 development phase so I'm moving this to 5.9.
--- Additional comment from slevine on 2011-11-03 14:20:17 EDT ---
Steve: As for point 1: This Bug is for RHEL 5. We cover this to some extent for RHEL 6, with the new documentation for gfs2_tool gettune, but I think I'll clone this for RHEL 6 as a placeholder to check (for the next release) if there's any information in here we don't cover in the RHEL 6 document that we should.
I'm looking at BZ#782801, about a new gfs2_lockgather script, which should address this bug when I document that script. But that script won't make 6.3 -- it will be in 6.4, so I'm moving this bug to 6.4 as well.