RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1396557 - ldif2db does not run the actual import if option -v ( verbose ) is used.
Summary: ldif2db does not run the actual import if option -v ( verbose ) is used.
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: 389-ds-base
Version: 7.3
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: pre-dev-freeze
: 7.4
Assignee: mreynolds
QA Contact: Viktor Ashirov
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-11-18 15:50 UTC by Têko Mihinto
Modified: 2020-09-13 21:53 UTC (History)
7 users (show)

Fixed In Version: 389-ds-base-1.3.6.1-3.el7
Doc Type: Bug Fix
Doc Text:
Cause: Incorrect usage and man pages incorrectly stated that "-v" would display verbose output. However this option is designed to print the Directory Server version only. Consequence: When using "-v" the script does not perform its task as expected Fix: Fix script usage and man pages to show the correct usage of the command line tool Result: The scripts usage and man page displays the correct information.
Clone Of:
Environment:
Last Closed: 2017-08-01 21:12:24 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github 389ds 389-ds-base issues 2103 0 None None None 2020-09-13 21:53:33 UTC
Red Hat Product Errata RHBA-2017:2086 0 normal SHIPPED_LIVE 389-ds-base bug fix and enhancement update 2017-08-01 18:37:38 UTC

Description Têko Mihinto 2016-11-18 15:50:54 UTC 
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)
#
Comment 2 Noriko Hosoi 2016-11-18 16:53:59 UTC 
Upstream ticket:
https://fedorahosted.org/389/ticket/49044
Comment 3 mreynolds 2017-03-01 20:48:12 UTC 
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.
Comment 5 Sankar Ramalingam 2017-05-15 07:49:02 UTC 
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
Comment 6 mreynolds 2017-05-15 13:47:27 UTC 
(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.
Comment 7 Sankar Ramalingam 2017-05-15 15:42:39 UTC 
Marking the bug as Verified based comment #5 and #6. Thanks Mark!
Comment 11 errata-xmlrpc 2017-08-01 21:12:24 UTC 
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
Note You need to log in before you can comment on or make changes to this bug.