IC Server fails to upgrade or server fails to start with the following errors: Invalid Event Type or Failed to log SERVER_SET_NOTIFY_PID_INORDER event in the debug.log.
Article ID: KB0086052
Updated On:
| Products | Versions |
|---|---|
| TIBCO InConcert | - |
| Not Applicable | - |
Description
Resolution:
For a UNIX server you will see errors in the debug.log of:
"14:39:18 ev/a 29432 t001: debug: Failed to log SERVER_SET_NOTIFY_PID_INORDER event"
"14:39:18 ev/a 29432 t001: debug: abnormal exit" and
"14:39:18 disp 29410 t001: debug: logServerStartupEvent - event.log failed -- <Error, Client, 21000>: Invalid Event Type".
In a Windows server you only see in the debug log the Invalid Event Type message.
The status.log for either platform will show:
"User Does Not Exist" and "Invalid Event Type" being reported by either the dispatcher or Event-Action daemon or by both.
The cause of these issues is updating the SERVER_NUMBER or INIT_DB_VERSION in SERVER_NAMES table of the database. Any time you change the server id or INIT_DB_VERSION from the ORIGINAL value used when the database was initialized you invalidate the database. The reason for this is all object ids created are based on the seed of the server id and INIT_DB_VERSION. Changing the values causes the server to lose essential system objects such as Permanent Job, EMPTY_POOL and icdba.
The way to fix this to change back to the original values used in the installation of InConcert. The way to find this to ask for several specific object ids.
select job_id, name from jobs where name='Permanent Job' OR name='BASE JOB
TEMPLATE'
select user_id, name from users where user='icdba';
select server_number from server_names;
select init_db_version from server_names;
The results were:
0x00000012 068e81b5 0000000100000400 for BASE JOB TEMPLATE,
0x00000012 068e81b5 0000000100000807 for Permanent Job,
0x00000012 068e81b5 0000000500000404 for icdba,
110005852 for server_number.
The server id are bytes 4 to 7 as two of the hex numbers make up a byte. I have formatted the above object ids with spaces around the server id. The server id embedded in the object id is a hex number while the server_number is decimal. Converting the hex object id of 068e81b5 gives 110002613 and not the current value of in server_number 110005852.
The solution is update the server_number. The SQL for this is 'update server_name set serve_number=XXXXX;' where XXXX is replaced by 110002613 in this case. ADDITIONALLY, IC_SERVER_ID must be updated in IC_HOME/current.cfg.
The init_db_version value is also part of the internal object id makeup and should be the same if the system is cloned. In this case it is the first set of bits, 0x00000012. A 7.1 server will have 16 there and a 7.2.x and 7.3 server will have 17.
For a UNIX server you will see errors in the debug.log of:
"14:39:18 ev/a 29432 t001: debug: Failed to log SERVER_SET_NOTIFY_PID_INORDER event"
"14:39:18 ev/a 29432 t001: debug: abnormal exit" and
"14:39:18 disp 29410 t001: debug: logServerStartupEvent - event.log failed -- <Error, Client, 21000>: Invalid Event Type".
In a Windows server you only see in the debug log the Invalid Event Type message.
The status.log for either platform will show:
"User Does Not Exist" and "Invalid Event Type" being reported by either the dispatcher or Event-Action daemon or by both.
The cause of these issues is updating the SERVER_NUMBER or INIT_DB_VERSION in SERVER_NAMES table of the database. Any time you change the server id or INIT_DB_VERSION from the ORIGINAL value used when the database was initialized you invalidate the database. The reason for this is all object ids created are based on the seed of the server id and INIT_DB_VERSION. Changing the values causes the server to lose essential system objects such as Permanent Job, EMPTY_POOL and icdba.
The way to fix this to change back to the original values used in the installation of InConcert. The way to find this to ask for several specific object ids.
select job_id, name from jobs where name='Permanent Job' OR name='BASE JOB
TEMPLATE'
select user_id, name from users where user='icdba';
select server_number from server_names;
select init_db_version from server_names;
The results were:
0x00000012 068e81b5 0000000100000400 for BASE JOB TEMPLATE,
0x00000012 068e81b5 0000000100000807 for Permanent Job,
0x00000012 068e81b5 0000000500000404 for icdba,
110005852 for server_number.
The server id are bytes 4 to 7 as two of the hex numbers make up a byte. I have formatted the above object ids with spaces around the server id. The server id embedded in the object id is a hex number while the server_number is decimal. Converting the hex object id of 068e81b5 gives 110002613 and not the current value of in server_number 110005852.
The solution is update the server_number. The SQL for this is 'update server_name set serve_number=XXXXX;' where XXXX is replaced by 110002613 in this case. ADDITIONALLY, IC_SERVER_ID must be updated in IC_HOME/current.cfg.
The init_db_version value is also part of the internal object id makeup and should be the same if the system is cloned. In this case it is the first set of bits, 0x00000012. A 7.1 server will have 16 there and a 7.2.x and 7.3 server will have 17.
Issue/Introduction
IC Server fails to upgrade or server fails to start with the following errors: Invalid Event Type or Failed to log SERVER_SET_NOTIFY_PID_INORDER event in the debug.log.
Feedback
Yes
No
Powered by
