db2iupgrade is failing due to duplicate matching records in
/etc/services
A db2iupgrade -d debug trace shows :
33002 |||||||\ 1 iPrepareServicesRecord EXIT Wed Apr 17
17:07:30 2013 -- , INT = 0
33003 ||||||| 1 IServiceFile::addService 50 -DATA- , INT =
-1879047688
33004 ||||||| 1 IServiceFile::addService 99 -ERROR- , STRING =
Duplicate matching record found
33005 |||||||/ 1 IServiceFile::setLastEcfError ENTRY Wed Apr 17
17:07:30 2013 -- ,
33006 |||||||| 1 IServiceFile::setLastEcfError 10 -DATA- , INT
= -1879047688
33007 |||||||\ 1 IServiceFile::setLastEcfError EXIT Wed Apr 17
17:07:30 2013 -- , INT = 0
33008 ||||||\ 1 IServiceFile::addService EXIT Wed Apr 17
17:07:30 2013 -- , INT = 5601
33009 |||||\ 1 IServiceFile::addService2 EXIT Wed Apr 17
17:07:30 2013 -- , INT = 5601
33010 ||||\ 1 ITCP::commitFCM EXIT Wed Apr 17 17:07:30 2013 --
, INT = 5601
33011 |||| 1 Instance::commit 90 -ERROR- , DATA = 00 00 15 e1
33012 |||\ 1 Instance::commit EXIT Wed Apr 17 17:07:30 2013 --
, INT = 5601
33013 ||| INFORMATION-1 UREMPPNode::initializeSettings 70 --
An error occurred while configuring the instance "db2inst1".
Duplicate records similar to following could be observed in
/etc/services
/etc/services shows duplicate ports :
comm_serv1 5616/tcp
DB2_db2inst1 5617/tcp
DB2_db2inst1_1 5618/tcp
DB2_db2inst1_2 5619/tcp
DB2_inst1_END 5620/tcp
comm_serv2 5616/tcp
DB2_db2inst2 5617/tcp
DB2_db2inst2_1 5618/tcp
DB2_db2inst2_2 5619/tcp
DB2_db2inst2_END 5620/tcp
/etc/services verification is not new to DB2, but it was changed
in a significant way in 10.1 . In 9.5 and 9.7 these checks
exist for new instance creation (not for upgrades), and are only
performed if GUI is used or silent installation method is used.
Neither command line installation, nor upgrades, would perform
this environmental validation in 9.5 and 9.7.
In 10.1, due to a number of serious customer issues where
incorrect service names and/or ports lead to other issues and
difficult to diagnose problems for different customers
production environments, these checks were made to common one
and now it affects both instance upgrade and new instance
creation.
After close review it's decided that shared /etc/services file
with duplicates is a valid and useful architecture for an LPAR'd
environment. So, this defect is created to fix the issue as
needed to get migrations to 10.1 succeed without failure due
to duplicate records. |
