#49174 connection handling is looping on timeout event
Closed: wontfix Opened by firstyear.

Ticket was cloned from Red Hat Bugzilla (product Fedora): Bug 1432917

Description of problem:
directory server log is getting flooded with the following warnings:
WARN - ns_handle_pr_read_ready - Received idletime out with c->c_idletimeout as
0. Ignoring.
Version-Release number of selected component (if applicable):
389-ds-base-1.3.6.2-2.fc26.x86_64
How reproducible:
always
Steps to Reproduce:
1. dnf update -y
2. dnf config-manager --enable=updates-testing
3. dnf install -y freeipa-server freeipa-server-dns
4. ipa-server-install -a $password -p $password --domain $domain --realm $realm
-U--setup-dns --auto-forwarders
Actual results:
IPA serve with DNS is installed and the mentioned warning message is logged in
directory server error log.
Expected results:
No such warning messages in error log.

Metadata Update from @firstyear:
- Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1432917

Metadata Update from @firstyear:
- Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1432917

Metadata Update from @firstyear:
- Issue assigned to firstyear

Metadata Update from @firstyear:
- Custom field reviewstatus adjusted to new
- Custom field type adjusted to defect
- Issue priority set to: 2
- Issue set to the milestone: 1.3.6.0 (was: 0.0 NEEDS_TRIAGE)
- Issue tagged with: Complex, Hot, Nunc Stans

The issue is related to #49171 : despite the fix, it looks like libevent / nunc-stans is still mis-firing events as timeouts even though they are set to 0.

This concerns me, and means I need to dig into it more. The reason for the log spam was to detect if the fix did not really work, or if we had spurious issues still. It looks like the issue is much larger.

My initial tests this only affects GSSAPI SASL binds.

(gdb) bt
#0  ns_handle_pr_read_ready (job=0x7f53d4053af0) at ldap/servers/slapd/daemon.c:1983
#1  0x00007f54150238c9 in work_job_execute (job=0x7f53d4053af0) at src/nunc-stans/ns/ns_thrpool.c:270
#2  0x00007f54126a6e90 in event_base_loop () from /lib64/libevent-2.0.so.5
#3  0x00007f541502494e in ns_event_fw_loop (ns_event_fw_ctx=<optimized out>) at src/nunc-stans/ns/ns_event_fw_event.c:318
#4  0x00007f5415023719 in event_loop_thread_func (arg=0x56519a03fd30) at src/nunc-stans/ns/ns_thrpool.c:544
#5  0x00007f54128e736d in start_thread () from /lib64/libpthread.so.0
#6  0x00007f54123d6e0f in clone () from /lib64/libc.so.6
(gdb) frame 1
#1  0x00007f54150238c9 in work_job_execute (job=0x7f53d4053af0) at src/nunc-stans/ns/ns_thrpool.c:270
270     job->func(job);
(gdb) print jox
No symbol "jox" in current context.
(gdb) print job
$1 = (ns_job_t *) 0x7f53d4053af0
(gdb) print *job
$2 = {monitor = 0x7f53d40436e0, tp = 0x56519a03fd30, func = 0x565197dc35a0 <ns_handle_pr_read_ready>, data = 0x7f53f0d2f280, job_type = 276, fd = 0x7f53d4010a10, tv = {tv_sec = -1, tv_usec = 0}, signal = 0, 
  ns_event_fw_fd = 0x7f53d4053b90, ns_event_fw_time = 0x0, ns_event_fw_sig = 0x0, output_job_type = 16, state = NS_JOB_RUNNING, ns_event_fw_ctx = 0x56519a03ff80, 
  alloc_event_context = 0x7f5415023290 <alloc_event_context>, free_event_context = 0x7f5415023fa0 <free_event_context>, event_cb = 0x7f5415023930 <event_cb>, done_cb = 0x0}

I was able to reproduce this, and can now confirm it is resolved.

"You remember professor Oak's voice ... remove that // comment"

Thanks!

Acked, and pushed

1179c07..2931cb9 master -> master

Metadata Update from @mreynolds:
- Custom field reviewstatus adjusted to ack (was: new)

Metadata Update from @firstyear:
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/2233

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: fixed)

Metadata