Bug 1663829
| Summary: | import task should not be deleted after import finishes to be able to query the status. | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | German Parente <gparente> | |
| Component: | 389-ds-base | Assignee: | thierry bordaz <tbordaz> | |
| Status: | CLOSED ERRATA | QA Contact: | RHDS QE <ds-qe-bugs> | |
| Severity: | unspecified | Docs Contact: | Marc Muehlfeld <mmuehlfe> | |
| Priority: | high | |||
| Version: | 7.6 | CC: | bsmejkal, joboyer, lkrispen, mreynolds, msauton, nkinder, rmeggins, spichugi, tbordaz, tmihinto, vashirov | |
| Target Milestone: | rc | Keywords: | ZStream | |
| Target Release: | 7.7 | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | ||||
| Fixed In Version: | 389-ds-base-1.3.9.1-1.el7 | Doc Type: | Bug Fix | |
| Doc Text: |
.The time after which Directory Server deletes tasks has been changed
Previously, Directory Server deleted task entries 2 minutes after a task finished. As a consequence, applications that were monitoring the task could miss the task result. This update changes the time after which the server deletes tasks. By default, all completed tasks are now deleted after 1 hour, except import and export tasks, which are deleted 24 hours after completion.
|
Story Points: | --- | |
| Clone Of: | ||||
| : | 1672173 (view as bug list) | Environment: | ||
| Last Closed: | 2019-08-06 12:59:10 UTC | Type: | Bug | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | ||||
| Bug Blocks: | 1672173 | |||
|
Description
German Parente
2019-01-07 08:18:34 UTC
Regarding failing tasks, it calls destroy_task (immediate DEL of the task). It should be possible to call slapi_task_finish (deferred DEL). Regarding successful task, import code is much different from others tasks code. At first look successful import should eventually calls slapi_task_finish but it does not take this path.
The problem is a task configuration issue.
When the task completes it registers a time event to delete the task entry. By default the task entry is kept for 2minutes then removed. The maximum duration of a completed task is 1hour.
It can be tuned with the 'ttl' attribute of the created task.
The default is likely too low (2min), will evaluate the appropriate value.
Unfortunately the ldif2db.pl script does not provide the ability to configure it.
Could you try the workaround (For example, setting timeout to 15min)
195,196c195
< $ttl = "ttl: 900";
< $entry = "${dn}${misc}${cn}${nsinstance}${nsincluded}${nsexcluded}${nsldiffiles}${nsnoattrindexes}${nsimportencrypt}${nsmergechunksiz}${nsgenuniqid}${nsuniqidname}${ttl}";
---
> $entry = "${dn}${misc}${cn}${nsinstance}${nsincluded}${nsexcluded}${nsldiffiles}${nsnoattrindexes}${nsimportencrypt}${nsmergechunksiz}${nsgenuniqid}${nsuniqidname}";
Upstream ticket: https://pagure.io/389-ds-base/issue/50177 Fix pushed upstream -> POST Build tested: 389-ds-base-1.3.9.1-4.el7.x86_64 # export_2019_4_23_3_23_11, export, tasks, config dn: cn=export_2019_4_23_3_23_11,cn=export,cn=tasks,cn=config objectClass: top objectClass: extensibleObject cn: export_2019_4_23_3_23_11 nsinstance: userRoot nsincludesuffix: dc=example,dc=com nsexportreplica: true nsuseonefile: true nsfilename: /tmp/export.ldif ttl: 86400 nstaskcurrentitem: 1 nstasktotalitems: 1 nstasklog:: QmVnaW5uaW5nIGV4cG9ydCBvZiAndXNlclJvb3QnCnVzZXJSb290OiBQcm9jZXNzZW QgOSBlbnRyaWVzICgxMDAlKS4KRXhwb3J0IGZpbmlzaGVkLg== nstaskstatus: userRoot: Processed 9 entries (100%). nstaskexitcode: 0 db2ldif task is now created with ttl: 84000 instead of 120. Same value is present for import task. Marking as Verified. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2019:2152 |