OpenIPMI threads deadlock

[yellowpattern]

• Version of collectd: 5.5.3
• Operating system / distribution: CentOS 6.6

Expected behavior

IPMI collection continues forever

Actual behavior

IPMI collection continues for a while then freezes up.
collectd needs to be restarted to recover from this problem.

gstack output below

Steps to reproduce

Start collectd with OpenIPMI to collect IPMI data then sit back and wait.

stack 32149
Thread 13 (Thread 0x7fc541217700 (LWP 32151)):
#0 0x00007fc54a7ef264 in __lll_lock_wait () from /lib64/libpthread.so.0
#1 0x00007fc54a7ea508 in _L_lock_854 () from /lib64/libpthread.so.0
#2 0x00007fc54a7ea3d7 in pthread_mutex_lock () from /lib64/libpthread.so.0
#3 0x00007fc548a06fd4 in ?? () from /usr/lib64/libOpenIPMIpthread.so.0
#4 0x00007fc548539a22 in _ipmi_domain_put () from /usr/lib64/libOpenIPMI.so.0
#5 0x00007fc54853afb9 in ipmi_domain_pointer_cb () from /usr/lib64/libOpenIPMI.so.0
#6 0x00007fc548545bcd in ipmi_mc_pointer_cb () from /usr/lib64/libOpenIPMI.so.0
#7 0x00007fc54855ebc2 in ipmi_sensor_pointer_cb () from /usr/lib64/libOpenIPMI.so.0
#8 0x00007fc548562b3b in ?? () from /usr/lib64/libOpenIPMI.so.0
#9 0x00007fc54854756a in ?? () from /usr/lib64/libOpenIPMI.so.0
#10 0x00007fc54853b1d1 in ?? () from /usr/lib64/libOpenIPMI.so.0
#11 0x00007fc54853b811 in ?? () from /usr/lib64/libOpenIPMI.so.0
#12 0x00007fc548537d59 in ipmi_handle_rsp_item_copymsg () from /usr/lib64/libOpenIPMI.so.0
#13 0x00007fc54859fbb5 in ?? () from /usr/lib64/libOpenIPMI.so.0
#14 0x00007fc548a095c7 in ?? () from /usr/lib64/libOpenIPMIpthread.so.0
#15 0x00007fc548a09b1e in sel_select () from /usr/lib64/libOpenIPMIpthread.so.0
#16 0x00007fc548a06e67 in ?? () from /usr/lib64/libOpenIPMIpthread.so.0
#17 0x00007fc548c0de6b in thread_main () from /usr/lib64/collectd/ipmi.so
#18 0x00007fc54a7e89d1 in start_thread () from /lib64/libpthread.so.0
#19 0x00007fc54a1288fd in clone () from /lib64/libc.so.6
Thread 12 (Thread 0x7fc53bfff700 (LWP 32152)):
Thread 6 (Thread 0x7fc532bfd700 (LWP 32160)):
#0 0x00007fc54a7ef264 in __lll_lock_wait () from /lib64/libpthread.so.0
#1 0x00007fc54a7ea508 in _L_lock_854 () from /lib64/libpthread.so.0
#2 0x00007fc54a7ea3d7 in pthread_mutex_lock () from /lib64/libpthread.so.0
#3 0x00007fc548a06fd4 in ?? () from /usr/lib64/libOpenIPMIpthread.so.0
#4 0x00007fc54853ac78 in _ipmi_domain_get () from /usr/lib64/libOpenIPMI.so.0
#5 0x00007fc54853afa1 in ipmi_domain_pointer_cb () from /usr/lib64/libOpenIPMI.so.0
#6 0x00007fc548545bcd in ipmi_mc_pointer_cb () from /usr/lib64/libOpenIPMI.so.0
#7 0x00007fc54855ebc2 in ipmi_sensor_pointer_cb () from /usr/lib64/libOpenIPMI.so.0
#8 0x00007fc54855ec86 in ipmi_sensor_id_get_reading () from /usr/lib64/libOpenIPMI.so.0
#9 0x00007fc548c0d541 in c_ipmi_read () from /usr/lib64/collectd/ipmi.so
#10 0x000000000040d1f2 in ?? ()

Not sure if this is an OpenIPMI bug or collectd?

[rpv-tomsk]

Hi!

As for me, that is a known issue of OpenIPMI-2.0.16. Please use OpenIPMI-2.0.22+.

[yellowpattern]

I'll update to OpenIPMI-2.0.24 in the New Year and see how it goes.

[rpv-tomsk]

Hi! Have you any news about, or we simply have to close the issue?

[yellowpattern]

Problem solved with OpenIPMI update. Please close.

…

On 15/1/18 6:10 pm, Pavel Rochnyak wrote: Hi! Have you any news about, or we simply have to close the issue? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#2632 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AXJ-tnfR_HQSBnGtsxizTyeR2iD991QGks5tKvn0gaJpZM4RJV2K>.

-- Darren Reed darren.reed@softelsystems.com.au M +61-0427970586