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.
When running rgmanager without the -q flag (the default), rgmanager can crash inside dbus library functions as a result of unlocked access to internal dbus data structures from different rgmanager threads.
I've observed the following crash (and others similar to it):
process 26806: The last reference on a connection was dropped without closing the connection. This is a bug in an application. See dbus_connection_unref() documentation for details.
Most likely, the application was supposed to call dbus_connection_close(), since this is a private connection.
D-Bus not built with -rdynamic so unable to print a backtrace
Aborted (core dumped)
(gdb) bt
#0 0x00007ff38ceed8a5 in raise () from /lib64/libc.so.6
#1 0x00007ff38ceef085 in abort () from /lib64/libc.so.6
#2 0x00007ff38d47f975 in _dbus_abort () at dbus-sysdeps.c:88
#3 0x00007ff38d47b845 in _dbus_warn_check_failed (
format=0x7ff38d484388 "The last reference on a connection was dropped without closing the connection. This is a bug in an application. See dbus_connection_unref() documentation for details.\n%s") at dbus-internals.c:283
#4 0x00007ff38d465c62 in _dbus_connection_read_write_dispatch (
connection=0xe573a0, timeout_milliseconds=500,
dispatch=<value optimized out>) at dbus-connection.c:3512
#5 0x000000000041b261 in ?? ()
#6 0x00007ff38d8a1851 in start_thread (arg=0x7ff38bea3700)
at pthread_create.c:301
#7 0x00007ff38cfa267d in clone () from /lib64/libc.so.6
The can be reproduced by repeatedly relocating and restarting services. I was able to reproduce it fairly reliably (albeit after a couple hours in some cases) by using the following configuration snippet:
<rm>
<service name="a"/>
<service name="b"/>
</rm>
and running the following commands at the same time on two nodes:
while [ 1 ] ; do clusvcadm -r a ; done
while [ 1 ] ; do clusvcadm -R a ; done
while [ 1 ] ; do clusvcadm -r b ; done
while [ 1 ] ; do clusvcadm -R b ; done
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
http://rhn.redhat.com/errata/RHBA-2013-0409.html
When running rgmanager without the -q flag (the default), rgmanager can crash inside dbus library functions as a result of unlocked access to internal dbus data structures from different rgmanager threads. I've observed the following crash (and others similar to it): process 26806: The last reference on a connection was dropped without closing the connection. This is a bug in an application. See dbus_connection_unref() documentation for details. Most likely, the application was supposed to call dbus_connection_close(), since this is a private connection. D-Bus not built with -rdynamic so unable to print a backtrace Aborted (core dumped) (gdb) bt #0 0x00007ff38ceed8a5 in raise () from /lib64/libc.so.6 #1 0x00007ff38ceef085 in abort () from /lib64/libc.so.6 #2 0x00007ff38d47f975 in _dbus_abort () at dbus-sysdeps.c:88 #3 0x00007ff38d47b845 in _dbus_warn_check_failed ( format=0x7ff38d484388 "The last reference on a connection was dropped without closing the connection. This is a bug in an application. See dbus_connection_unref() documentation for details.\n%s") at dbus-internals.c:283 #4 0x00007ff38d465c62 in _dbus_connection_read_write_dispatch ( connection=0xe573a0, timeout_milliseconds=500, dispatch=<value optimized out>) at dbus-connection.c:3512 #5 0x000000000041b261 in ?? () #6 0x00007ff38d8a1851 in start_thread (arg=0x7ff38bea3700) at pthread_create.c:301 #7 0x00007ff38cfa267d in clone () from /lib64/libc.so.6 The can be reproduced by repeatedly relocating and restarting services. I was able to reproduce it fairly reliably (albeit after a couple hours in some cases) by using the following configuration snippet: <rm> <service name="a"/> <service name="b"/> </rm> and running the following commands at the same time on two nodes: while [ 1 ] ; do clusvcadm -r a ; done while [ 1 ] ; do clusvcadm -R a ; done while [ 1 ] ; do clusvcadm -r b ; done while [ 1 ] ; do clusvcadm -R b ; done