On Fri, May 14, 2021 at 01:36:12PM -0000, Stephane Chazelas wrote: >The important backtrace in there is the one from thread 11: > >#0 0x00007fb288428474 in read () from /lib/x86_64-linux-gnu/libpthread.so.0 >No symbol table info available. >#1 0x00007fb2890c4518 in ?? () from /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2 >No symbol table info available. >#2 0x00007fb287895848 in ?? () from /usr/lib/x86_64-linux-gnu/libgnutls.so.30 >No symbol table info available.
This is a valid issue, but are we certain it's the same one? The reporter talked about sched_yield and their backtraces included several threads of back_monitor waiting on some kind of lock. >https://bugs.openldap.org/show_bug.cgi?id=8650#c12 explains that it's >https://github.com/openldap/openldap/commit/7b5181da8cdd47a13041f9ee36fa9590a0fa6e48 >that is responsible for the issue. > >https://github.com/openldap/openldap/commit/4c1ab16ade18a253dd81df7e6eced4d920ac6a8e >reverted that commit, but that one did not make it into bionic. Indeed. :( I didn't notice this went unfixed in an LTS, I'm sorry for missing that. >So cherry picking >https://github.com/openldap/openldap/commit/4c1ab16ade18a253dd81df7e6eced4d920ac6a8e >should fix it. In this version it's a Debian patch, so probably just remove the offending patch from d/patches, rather than import the revert? On Fri, May 14, 2021 at 02:18:47PM -0000, Stephane Chazelas wrote: >Yes, >https://github.com/openldap/openldap/commit/735e1ab14bb055344b4e767a216aa410aa7d1503 >can't be directly applied there. There have been other changes in >between in that section including changes in API, so it would take more >effort to backport that fix. Right. I'm not confident I can backport that correctly, so I'd feel safer just doing the revert. However, sssd should also be tested, to ensure the version in bionic isn't affected by ITS#9210 (https://bugs.openldap.org/show_bug.cgi?id=9210). COMPLETELY UNTESTED debdiff attached. ** Bug watch added: bugs.openldap.org/ #9210 https://bugs.openldap.org/show_bug.cgi?id=9210 ** Attachment added: "openldap_2.4.45+dfsg-1ubuntu1.11.debdiff" https://bugs.launchpad.net/bugs/1926265/+attachment/5497610/+files/openldap_2.4.45+dfsg-1ubuntu1.11.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openldap in Ubuntu. https://bugs.launchpad.net/bugs/1926265 Title: slapd enter in infinite loop on sched_yield syscall Status in openldap package in Ubuntu: Confirmed Bug description: On a production server, sometimes slapd become unbresponsive, some threads loops in sched_yield syscall and consumme all CPU. To recover, slapd needs to restart. No related information is reported in log file. All same issues in OpenLDAP upstream project are old and fixed. So maybe this issue affects only Ubuntu package. It occurs randomly, so I have no steps to reproduce. OS : Bionic Openldap version: libldap-2.4-2:amd64 2.4.45+dfsg-1ubuntu1.10 libldap-common 2.4.45+dfsg-1ubuntu1.10 slapd 2.4.45+dfsg-1ubuntu1.10 Modules loaded: olcModuleLoad: {0}back_bdb olcModuleLoad: {1}syncprov olcModuleLoad: {2}back_monitor olcModuleLoad: {3}memberof.la olcModuleLoad: {4}refint.la olcModuleLoad: {5}rwm olcModuleload: {6}back_ldap Backend is BDB. slapd run in (single) master - (multi) slave mode. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1926265/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
