Description of problem: In lib389/tasks.py, there is a timeout of 120 * 2 seconds ( 4 minutes ) when a new task is created. In case the task takes longer, dsconf returns the following message: ========================================== ... DEBUG: The backup create task has failed with the error code: (None) Traceback (most recent call last): File "/usr/sbin/dsconf", line 134, in <module> result = args.func(inst, None, log, args) File "/usr/lib/python3.6/site-packages/lib389/cli_conf/backup.py", line 20, in backup_create raise ValueError("The backup create task has failed with the error code: ({})".format(result)) ValueError: The backup create task has failed with the error code: (None) ERROR: Error: The backup create task has failed with the error code: (None) ========================================== It would be nice to: * allow dsconf to specify a timeout ( maybe this is already possible but I don't see any documented option ) * provide additional information stating that the timeout was over. Version-Release number of selected component (if applicable): $ cat /etc/redhat-release Red Hat Enterprise Linux release 8.4 (Ootpa) $ $ rpm -qa | grep 389-ds-base 389-ds-base-debugsource-1.4.3.13-1.module+el8dsrv+8334+69a46a2e.x86_64 389-ds-base-libs-1.4.3.22-1.module+el8dsrv+10501+8ce33e95.x86_64 389-ds-base-debuginfo-1.4.3.13-1.module+el8dsrv+8334+69a46a2e.x86_64 389-ds-base-1.4.3.22-1.module+el8dsrv+10501+8ce33e95.x86_64 $ How reproducible: Always. Steps to Reproduce: 1. Launch a task that will last longer than 4 minutes. 2. Check the output of the dsconf command 3. Check the errors log Actual results: The dsconf command fails and returns no reason for the failure. Expected results: * Allow to specify the timeout * Provide additional information about the failure. Additional info: Issue was seen at a customer site. I could reproduce by reducing the timeout value in /usr/lib/python3.6/site-packages/lib389/tasks.py in the wait() function. $ dsconf -v -D "cn=Directory Manager" ldap://localhost:5389 backup create ... DEBUG: cn=backup_2021-08-11T17:49:34.483894,cn=backup,cn=tasks,cn=config getVal('nsTaskExitCode') DEBUG: cn=backup_2021-08-11T17:49:34.483894,cn=backup,cn=tasks,cn=config getVal('nsTaskLog') DEBUG: cn=backup_2021-08-11T17:49:34.483894,cn=backup,cn=tasks,cn=config getVal('nsTaskWarning') DEBUG: cn=backup_2021-08-11T17:49:34.483894,cn=backup,cn=tasks,cn=config getVal('nsTaskExitCode') DEBUG: cn=backup_2021-08-11T17:49:34.483894,cn=backup,cn=tasks,cn=config getVal('nsTaskLog') DEBUG: cn=backup_2021-08-11T17:49:34.483894,cn=backup,cn=tasks,cn=config getVal('nsTaskWarning') DEBUG: The backup create task has failed with the error code: (None) Traceback (most recent call last): File "/usr/sbin/dsconf", line 134, in <module> result = args.func(inst, None, log, args) File "/usr/lib/python3.6/site-packages/lib389/cli_conf/backup.py", line 20, in backup_create raise ValueError("The backup create task has failed with the error code: ({})".format(result)) ValueError: The backup create task has failed with the error code: (None) ERROR: Error: The backup create task has failed with the error code: (None) $
As the RHEL 8.5 reached EOL, it makes sense to move this BZ to dirsrv-11.5, which means RHEL 8.6.
Upstream ticket: https://github.com/389ds/389-ds-base/issues/5666
Peer comment were applied. RN text is release pending
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 (redhat-ds:12 bug fix and enhancement update), 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-2023:3344