Thank you, Viktor!

This is not a release stopper for 7.1; setting the target to 7.2 per weekly mtg.

Upstream ticket:
https://fedorahosted.org/389/ticket/48007

Hi Viktor,

It seems Mark and Willam failed to duplicate the problem.
(See https://fedorahosted.org/389/ticket/48007)

Is it okay to close this bug for now?
Please feel free to reopen it when you run into it.
Probably, you could let us access your test env once you see the bug again?

Thanks!

With the steps given in description I'm still able to reproduce it.

William and Viktor, I think you'd better talk on the same page... :)

https://fedorahosted.org/389/ticket/48007#comment:10
> I can reproduce "getting the change log to trim" but in my tests, it appears that the moment I set the new trim time, it's taking effect immediately, and correctly. I think this is actually not an issue, and the difference in log times is a co-incidence.
>
> I would like to close this as "not a bug" if that's okay with you, but I am happy to discuss it more if you like. Do you still want the test case that proves it's not an issue?

I tried William's test on the affected version, it fails with

        # Now parse the trim_event lines. We should only see 5 seconds between them.
        # This test basically should generate 3 trim events.
        # The first one from the server setup, one from the first add, a third from the last.
>       assert(len(trim_events) >= 3)
E       assert 0 >= 3
E        +  where 0 = len([])


On 389-ds-base-1.3.5.4-1.el7.x86_64:
        # Now parse the trim_event lines. We should only see 5 seconds between them.
        # This test basically should generate 3 trim events.
        # The first one from the server setup, one from the first add, a third from the last.
>       assert(len(trim_events) >= 3)
E       assert 2 >= 3
E        +  where 2 = len(['[31/May/2016:09:31:06.492981568 -0400] Trimmed 17 changes from the changelog\n', '[31/May/2016:09:31:13.797244226 -0400] Trimmed 9 changes from the changelog\n'])

Actually in the logs:
grep trim /var/log/dirsrv/slapd-master_1/errors -i
[31/May/2016:09:31:06.492981568 -0400] Trimmed 17 changes from the changelog
[31/May/2016:09:31:13.797244226 -0400] Trimmed 9 changes from the changelog
[31/May/2016:09:36:13.947764120 -0400] Trimmed 11 changes from the changelog

I don't know why it took 5 minutes to trim last changes.

Created attachment 1163243 [details]
ticket48007_test.py

I can confirm that 1.3.7 works correctly.  Perhaps the test case is flawed, but I stepped through the code and everything is working after changing the trim interval.  The trimming thread wakes up right after the config change as you would expect, and it does trim entries (if those entries have exceeded the changelog maxage).

Created attachment 1345973 [details]
verification lib389 test script

This is a revised test case that shows the server is working as expected