Hide Forgot
Description of problem: I was trying to get additional information from the ldif2db command. I have tried the option -v which is supposed to provide a verbose output: # ldif2db -h Usage: ldif2db [-Z serverID] -n backendname {-s includesuffix}* [{-x excludesuffix}*] {-i ldiffile}* ... -v - Verbose output ... # But when using this option the ldif2db command only prints some version information and exits: # ldif2db -n TekoSoft -i /var/tmp/TekoSoft.ldif -v importing data ... 389 Project 389-Directory/1.3.5.10 B2016.257.1817 # Version-Release number of selected component (if applicable): # rpm -qa | grep 389-ds-base 389-ds-base-libs-1.3.5.10-11.el7.x86_64 389-ds-base-1.3.5.10-11.el7.x86_64 # How reproducible: Always. Steps to Reproduce: Run ldif2db with the option -v. It will print RHDS version and then exit: # ldif2db -n TekoSoft -i /var/tmp/TekoSoft.ldif -v importing data ... 389 Project 389-Directory/1.3.5.10 B2016.257.1817 # Actual results: No import happens. Expected results: Import of the LDIF file. Additional info: The import works fine if the option -v is not used: # ldif2db -n TekoSoft -i /var/tmp/TekoSoft.ldif importing data ... [18/Nov/2016:16:17:57.460540605 +0100] WARNING: Import is running with nsslapd-db-private-import-mem on; No other process is allowed to access the database [18/Nov/2016:16:17:57.463728688 +0100] check_and_set_import_cache: pagesize: 4096, pages: 237114, procpages: 3305 [18/Nov/2016:16:17:57.466131684 +0100] WARNING: After allocating import cache 134104KB, the available memory is 814352KB, which is less than the soft limit 1048576KB. You may want to decrease the import cache size and rerun import. [18/Nov/2016:16:17:57.468650665 +0100] Import allocates 134104KB import cache. [18/Nov/2016:16:17:57.484584088 +0100] import TekoSoft: Beginning import job... [18/Nov/2016:16:17:57.487067637 +0100] import TekoSoft: Index buffering enabled with bucket size 92 [18/Nov/2016:16:17:57.688975182 +0100] import TekoSoft: Processing file "/var/tmp/TekoSoft.ldif" [18/Nov/2016:16:17:57.692722429 +0100] import TekoSoft: Finished scanning file "/var/tmp/TekoSoft.ldif" (9 entries) [18/Nov/2016:16:17:58.191080505 +0100] import TekoSoft: Workers finished; cleaning up... [18/Nov/2016:16:17:58.394001443 +0100] import TekoSoft: Workers cleaned up. [18/Nov/2016:16:17:58.396948948 +0100] import TekoSoft: Cleaning up producer thread... [18/Nov/2016:16:17:58.399403536 +0100] import TekoSoft: Indexing complete. Post-processing... [18/Nov/2016:16:17:58.401587350 +0100] import TekoSoft: Generating numsubordinates (this may take several minutes to complete)... [18/Nov/2016:16:17:58.406603023 +0100] import TekoSoft: Generating numSubordinates complete. [18/Nov/2016:16:17:58.408757778 +0100] import TekoSoft: Gathering ancestorid non-leaf IDs... [18/Nov/2016:16:17:58.410678323 +0100] import TekoSoft: Finished gathering ancestorid non-leaf IDs. [18/Nov/2016:16:17:58.414702494 +0100] import TekoSoft: Creating ancestorid index (new idl)... [18/Nov/2016:16:17:58.416745788 +0100] import TekoSoft: Created ancestorid index (new idl). [18/Nov/2016:16:17:58.418648983 +0100] import TekoSoft: Flushing caches... [18/Nov/2016:16:17:58.420537937 +0100] import TekoSoft: Closing files... [18/Nov/2016:16:17:58.449468844 +0100] All database threads now stopped [18/Nov/2016:16:17:58.451571216 +0100] import TekoSoft: Import complete. Processed 9 entries in 1 seconds. (9.00 entries/sec) #
Upstream ticket: https://fedorahosted.org/389/ticket/49044
This was a usage issue. The "-v" option only prints the server version in the shell scripts. I fixed all the scripts' usage and man pages. I need to file doc bugs to correct any existing documentation that incorrectly says "-v" prints verbose output.
I tested import with latest build of 389-ds-base-1.3.6.1-13 and its working fine for "-v" option. It prints the Directory Server related information. However, the actual the problem doesn't seems to be fixed. When "-v" option is used along with other import options, import just prints the Directory server information and exits. The import doesn't happen. I am not sure if this is the expected behavior since "-v" option is supposed to print only the information. Please clarify [0 root@qeos-130 ~]# ldif2db -Z qeos-130 -n importest1389 -v -i /var/lib/dirsrv/slapd-qeos-130/ldif/import.ldif importing data ... 389 Project 389-Directory/1.3.6.1 B2017.125.237 [0 root@qeos-130 ~]# ldif2db -Z qeos-130 -n importest1389 -i /var/lib/dirsrv/slapd-qeos-130/ldif/import.ldif importing data ... [15/May/2017:03:45:13.307218715 -0400] - INFO - ldbm_instance_config_cachememsize_set - force a minimal value 512000 [15/May/2017:03:45:13.313213027 -0400] - INFO - ldbm_instance_config_cachememsize_set - force a minimal value 512000 [15/May/2017:03:45:13.316932722 -0400] - INFO - ldbm_instance_config_cachememsize_set - force a minimal value 512000 [15/May/2017:03:45:13.321937371 -0400] - INFO - dblayer_instance_start - Import is running with nsslapd-db-private-import-mem on; No other process is allowed to access the database
(In reply to Sankar Ramalingam from comment #5) > I tested import with latest build of 389-ds-base-1.3.6.1-13 and its working > fine for "-v" option. It prints the Directory Server related information. > However, the actual the problem doesn't seems to be fixed. When "-v" option > is used along with other import options, import just prints the Directory > server information and exits. The import doesn't happen. I am not sure if > this is the expected behavior since "-v" option is supposed to print only > the information. Please clarify > Hi Sankar, this is the intended behavior (whether it is correct or not is another debate), but in our other tools if you use "-v" to display the version that's all its supposed to do - it's not supposed to perform the task, just display the version.
Marking the bug as Verified based comment #5 and #6. Thanks Mark!
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-2017:2086