IBM Support

DBI1281E error creating DB2 instance with idsxinst or idsicrt

Technote (troubleshooting)


Problem(Abstract)

This solution provides some hints for how to resolve a problem creating a DB2 instance with the idsxinst or idsicrt tools when setting up an SDS / TDS instance.

Resolving the problem

If the following errors occurs in idsicrt or idsxinst output:

GLPCTL004E Failed to create database instance: 'ldapdb2'. The failure might have occurred because the system was not setup correctly before using the tool.

GLPICR033E Failed to add database instance 'db2inst1' to directory server instance: 'ldapdb2'.

This is usually a problem with the local server configuration so that a DB2 instance can't be created.

First, be careful to make sure these are the errors you are receiving. There are a number of DB2-related errors you can receive, and they can look very similar to this one.

The first thing to try when getting errors like this is to try and create the same DB2 instance outside of the SDS / TDS tools. Our tools create a DB2 instance in almost the same fashion as one would do it from the command line (the main difference would be the shell environment):

(This note will use 'ldapdb2' as the ldap/db2 instance owner.)

a) Check to see if the DB2 instance already exists (as root):
cd <DB2_Install_dir>/instance
./db2ilist

Does 'ldapdb2' show up in the list? Probably not, if you're getting
the error above. (If it does exist, drop it by doing: './db2idrop
ldapdb2'. It's better to let the SDS / TDS tools create the db2 instance.)

b) ./db2icrt -d -u ldapdb2 ldapdb2 > /tmp/db2icrt_debug.log
2> /tmp/db2icrt_debug.log

Does this command also fail? If so, the issue is really a DB2 issue.
(Often, SDS / TDS Support will send your issue to DB2 Level 2 at this point,
since the problem exists entirely outside of SDS / TDS.) However, they are
often issues that aren't overly difficult to debug.

If the following error occurs:

DBI1281E The database manager configuration file could not be initialized.

in the DB2 debug output (usually in the /tmp/db2icrt.log.<pid> file),
the most important thing to check is name resolution. For example, if
the host has a specific hostname, let's say foo.domain.com, and DNS
can't resolve an ip address:

nslookup foo.domain.com

nslookup foo.domain.com
Server: nnn.nnn.nnn.nnn
Address: nnn.nnn.nnn.nnn#53

** server can't find foo.domain.com: NXDOMAIN

and there's no entry for foo.domain.com in /etc/hosts (and there's no
additional means to resolve hostnames), then the above error can occur.
Adding an entry in the hosts file (/etc/hosts on UNIX and Linux, for
example) with the proper ip address pointing at the server's hostname
should resolve this.

This error could also occur if the db2 instance owner user (ie, the last
argument passed into the db2icrt command) doesn't have write permission
to /tmp on UNIX and Linux systems.

Once db2icrt successfully creates a DB2 instance, it's usually a good
idea to drop the DB2 instance, and let idsxinst or idsicrt create a new
one:

cd /opt/ibm/ldap/V6.0/db2/instance
./db2idrop ldapdb2

Then try the original command used to try and create the SDS / TDS instance.

Document information

More support for: IBM Security Directory Server
General

Software version: 6.0, 6.1, 6.2, 6.3, 6.3.1, 6.4

Operating system(s): AIX, HP-UX, Linux, Solaris

Reference #: 1259825

Modified date: 17 June 2008