Thanks.
I notice your first write() is on fd 3 while the 2nd is on stdout (while
for me the first 2 are on fd 3, which in my case is the LDAPS socket).
For the issue to be reproduced, we need the client to be paused after
having send the TLS "client hello".
The first time the breakpoint is hit, you should be seeing something
like:
```
#0 __GI___libc_write (fd=3, buf=0x555555ace4ab, nbytes=75) at
../sysdeps/unix/sysv/linux/write.c:27
#1 0x00007ffff797b408 in sb_debug_write (sbiod=0x555555ab4810,
buf=0x555555ace4ab, len=75) at ../../../../libraries/liblber/sockbuf.c:854
#2 0x00007ffff6bd5a0a in _gnutls_writev_emu (fd=fd@entry=0x55555578f240,
giovec=giovec@entry=0x7fffffff9b90, giovec_cnt=giovec_cnt@entry=3,
vec=0, session=<optimized out>, session=<optimized out>) at buffers.c:447
#3 0x00007ffff6bd608c in _gnutls_writev (total=126, giovec_cnt=3,
giovec=0x7fffffff9b90, session=0x55555578d3d0) at buffers.c:504
#4 _gnutls_io_write_flush (session=session@entry=0x55555578d3d0) at
buffers.c:698
#5 0x00007ffff6bd7200 in _gnutls_handshake_io_write_flush
(session=session@entry=0x55555578d3d0) at buffers.c:820
#6 0x00007ffff6bd9348 in _gnutls_send_handshake
(session=session@entry=0x55555578d3d0, bufel=bufel@entry=0x555555acd620,
type=type@entry=GNUTLS_HANDSHAKE_FINISHED) at handshake.c:1335
#7 0x00007ffff6bda4ed in _gnutls_send_finished (again=<optimized out>,
session=0x55555578d3d0) at handshake.c:763
#8 send_handshake_final (session=session@entry=0x55555578d3d0,
init=init@entry=1) at handshake.c:3098
#9 0x00007ffff6bdcd29 in handshake_client (session=0x55555578d3d0) at
handshake.c:2946
#10 gnutls_handshake (session=0x55555578d3d0) at handshake.c:2626
#11 0x00007ffff7bbb183 in tlsg_session_accept (session=0x555555abb070) at
tls_g.c:361
#12 0x00007ffff7bb8751 in ldap_int_tls_connect (ld=ld@entry=0x5555557890d0,
conn=<optimized out>) at tls2.c:362
#13 0x00007ffff7bb9466 in ldap_int_tls_start (ld=ld@entry=0x5555557890d0,
conn=conn@entry=0x555555789500, srv=srv@entry=0x555555789440)
at tls2.c:860
#14 0x00007ffff7b912b6 in ldap_int_open_connection (ld=ld@entry=0x5555557890d0,
conn=conn@entry=0x555555789500, srv=0x555555789440,
async=async@entry=0) at open.c:448
#15 0x00007ffff7ba634d in ldap_new_connection (ld=ld@entry=0x5555557890d0,
srvlist=srvlist@entry=0x555555789198, use_ldsb=use_ldsb@entry=1,
connect=connect@entry=1, bind=bind@entry=0x0, m_req=m_req@entry=0, m_res=0)
at request.c:487
#16 0x00007ffff7b9074a in ldap_open_defconn (ld=ld@entry=0x5555557890d0) at
open.c:41
#17 0x00007ffff7ba7908 in ldap_send_initial_request
(ld=ld@entry=0x5555557890d0, msgtype=msgtype@entry=96, dn=dn@entry=0x0,
ber=0x5555557894a0,
msgid=1) at request.c:130
#18 0x00007ffff7b9ab8f in ldap_sasl_bind (ld=0x5555557890d0, dn=0x0,
mechanism=<optimized out>, cred=0x5555557692e0 <passwd>, sctrls=0x0,
cctrls=0x0, msgidp=0x7fffffffa2dc) at sasl.c:164
#19 0x000055555555d33b in ?? ()
#20 0x000055555555844f in ?? ()
#21 0x00007ffff7388bf7 in __libc_start_main (main=0x5555555581b0, argc=4,
argv=0x7fffffffe638, init=<optimized out>, fini=<optimized out>,
rtld_fini=<optimized out>, stack_end=0x7fffffffe628) at
../csu/libc-start.c:310
#22 0x000055555555966a in ?? ()
```
And we need to make sure the server or client doesn't reject that
connection outright.
It would worth running "tshark -i any -f 'port 636'" in the mean time to
verify the "client hello" is sent and that the server is willing to
carry on the connection.
--
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
