Description of problem: When a "Can't open file" type of error occurs, db2ldif command line does not display the error. Seeing the ldiffile path displayed is misleading and makes think that the file as actually been created. Nothing shows that the operation couldn't be performed, unless looking at the errors log Version-Release number of selected component (if applicable): 389-ds-base-1.4.3.8-4.module+el8.3.0+7193+dfd1e8ad.x86_64 How reproducible: always Steps to Reproduce: automated test export/export_test.py::test_db2ldif_with_non_accessible_ldif_file_path will be sent soon as PR for review or 1. import data in "dc=example,dc=com" 2. stop the ds instance 3. run # db2ldif -Z standalone1 -s "dc=example,dc=com" -a ldif/db.ldif Actual results: # db2ldif -Z standalone1 -s "dc=example,dc=com" -a ldif/db.ldif Exported ldif file: /mnt/tests/rhds/tests/upstream/ldif/db.ldif [24/Jul/2020:04:55:06.947184501 -0400] - INFO - slapd_exemode_db2ldif - db2ldif - Backend Instance(s): [24/Jul/2020:04:55:06.952243624 -0400] - INFO - slapd_exemode_db2ldif - db2ldif - userRoot ldiffile: /mnt/tests/rhds/tests/upstream/ldif/db.ldif Expected results: The error should be displayed as command output, in addition of info already displayed : [24/Jul/2020:04:55:06.976484643 -0400] - ERR - bdb_db2ldif - db2ldif: userRoot: can't open /mnt/tests/rhds/tests/upstream/ldif/db.ldif: 2 (No such file or directory) while running as user "dirsrv" It should be clear that ldiffile: /mnt/tests/rhds/tests/upstream/ldif/db.ldif couldn't be created and that the operation failed Additional info:
Not having the error collected in output stream leads to lib389 debug message being incomplete : DEBUG:lib389:Command: /usr/sbin/ns-slapd db2ldif -D /etc/dirsrv/slapd-standalone1 -n userRoot -s dc=example,dc=com -a /root/export.ldif failed with the return code 255 and the error Having the error displayed would be useful
To be noted that 'dsctl db2ldif' doesn't redirect either the cmd output on the terminal, when specifying a output file which cannot be accessed : # /usr/sbin/ns-slapd db2ldif -D /etc/dirsrv/slapd-standalone1 -n userRoot -a /tmp/nonexistent/export.ldif ldiffile: /tmp/nonexistent/export.ldif With such an output, it is not possible straight away to know that the command failed. For a better user experience, and for consistency, one should have displayed at least an extract of the errors log, as it is the case for other error misusage cases. For example, we should have something like : [28/Sep/2020:04:37:28.496635032 -0400] - ERR - bdb_db2ldif - db2ldif: userRoot: can't open /tmp/nonexistent/export.ldif: 2 (No such file or directory) while running as user "dirsrv"
Is this problem reproducible with dsctl ? Else we will close it (no enhancement on legacy tools)
With dsctl it's even worse as it doesn't display any output why the command failed, please see comment #2.
Thanks Viktor for the confirmation. As it is likely an easy fix to for this usability issue, I moved its jira ticket to the top
Upstream ticket: https://github.com/389ds/389-ds-base/issues/5632
Automated test passed: ============================================================= test session starts ============================================================= platform linux -- Python 3.9.16, pytest-6.2.2, py-1.10.0, pluggy-0.13.1 -- /usr/bin/python3 cachedir: .pytest_cache 389-ds-base: 2.2.7-2.module+el9dsrv+18726+78959e84 nss: 3.79.0-18.el9_1 nspr: 4.34.0-18.el9_1 openldap: 2.6.2-3.el9 cyrus-sasl: not installed FIPS: disabled rootdir: /root/ds/dirsrvtests, configfile: pytest.ini collected 1 item dirsrvtests/tests/suites/export/export_test.py::test_db2ldif_cli_with_non_accessible_ldif_file_path PASSED [100%] ======================================================= 1 passed, 5 warnings in 30.35s ======================================================== db2ldif prints an error: # dsctl standalone1 db2ldif userroot /tmp/nonexistent/export.ldif Error: The LDIF file location does not exist: /tmp/nonexistent/export.ldif 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 (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