Version-Release number of selected component: realmd-0.16.2-5.fc25 Additional info: reporter: libreport-2.8.0 backtrace_rating: 4 cmdline: /usr/lib/realmd/realmd crash_function: __netlink_assert_response executable: /usr/lib/realmd/realmd global_pid: 1630 kernel: 4.8.6-300.fc25.x86_64 pkg_fingerprint: 4089 D8F2 FDB1 9C98 pkg_vendor: Fedora Project runlevel: N 5 type: CCpp uid: 0 Truncated backtrace: Thread no. 1 (7 frames) #4 __netlink_assert_response at ../sysdeps/unix/sysv/linux/netlink_assert_response.c:103 #5 make_request at ../sysdeps/unix/sysv/linux/check_pf.c:171 #6 __check_pf at ../sysdeps/unix/sysv/linux/check_pf.c:329 #7 getaddrinfo at ../sysdeps/posix/getaddrinfo.c:2338 #8 do_lookup_by_name at gthreadedresolver.c:79 #9 g_task_thread_pool_thread at gtask.c:1304 #11 g_thread_proxy at gthread.c:784
Created attachment 1224121 [details] File: backtrace
Created attachment 1224122 [details] File: cgroup
Created attachment 1224123 [details] File: core_backtrace
Created attachment 1224124 [details] File: dso_list
Created attachment 1224125 [details] File: environ
Created attachment 1224126 [details] File: limits
Created attachment 1224127 [details] File: maps
Created attachment 1224128 [details] File: mountinfo
Created attachment 1224129 [details] File: namespaces
Created attachment 1224130 [details] File: open_fds
Created attachment 1224131 [details] File: proc_pid_status
Created attachment 1224132 [details] File: var_log_messages
This glibc assert intends to catch cases where the internal file descriptor used for Netlink processing has been closed by another thread. EBADF suggests that this has happened here. This could have been caused by a race internal to glibc, but we have not seen this yet anywhere since we added the assert, so I suspect it's an application bug.
Can you reproduce the issue reliable? I was able to reproduce it by chance and created a test build at https://koji.fedoraproject.org/koji/taskinfo?taskID=16657441 . Can you check if it fixes the issue for you?
Created attachment 1225807 [details] [PATCH] LDAP: don't close LDAP socket twice Hi Stef, can you check the attached patch? I wonder what was the original motivation to call close() before ldap_destroy(). Did you had any issues with a blocking ldap_destroy()?
Comment on attachment 1225807 [details] [PATCH] LDAP: don't close LDAP socket twice Can ldap_destroy() block when the LDAP server is no longer reachable? Once that question is answered, the patch looks good to me.
I did some basic test calling ldap_initialize(), ldap_search_ext() and ldap_destroy(). Before calling ldap_destroy() I either paused the VM running the LDAP server or killed the LDAP server process in the VM. In both cases ldap_destroy() didn't block.
Patch merged into realmd git master.
realmd-0.16.2-6.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-b06e7168c9
realmd-0.16.2-6.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-b06e7168c9
realmd-0.16.2-6.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.