Applies to:
Siebel System Software - Version 7.5.2.100 SIA [15252] to 8.1.1.4 SIA [21225] [Release V7 to V8]
z*OBSOLETE: Microsoft Windows 2000
Product Release: V7 (Enterprise)
Version: 7.5.2.100 [15252] Life Sci
Database: Oracle 8.1.7
Application Server OS: Microsoft Windows 2000 Advanced Server SP 2
Database Server OS: Microsoft Windows 2000 Advanced Server SP 2
This document was previously published as Siebel SR 38-1020255192.
CHECKED FOR RELEVANCE ON 1-FEB-2013
Symptoms
SBL-SMI-00033, SBL-SRB-00041, SBL-NET-01034
Typical error is as follows:
2021 2003-06-04 00:30:05
2003-06-04 00:30:05 +0100 00000042 001 ffff 0001 09 SRBroker 36931 548
592 E:\sea752\siebsrvr\log\SRBroker_36931.log 7.5.2.102 [15255] ENUENU
GenericLog GenericError 1 2003-06-04
00:30:05 (smimtses.cpp 18(352) err=2100033 sys=0) SMI-00033: The
client exited without closing the SISNAPI connection
TaskCfgExit TaskParamsAtExit 1 2003-06-04
00:30:05 ***********Dumping Parameters for the current task because
of errors**********
In addition to this SRBroker error:
2021
2003-05-29 14:46:49 2003-05-29 14:46:49 +0100 00000046 001 ffff 0001 09
SRBroker 20550 2484 2508 E:\sea752\siebsrvr\log\SRBroker_20550.log
7.5.2.102 [15255] ENUENU
GenericLog GenericError 1 2003-05-29
14:46:49 (srbthrd.cpp 44(2445) err=1801033 sys=0) NET-01033: The
SISNAPI handshake timed out, the Siebel Service may not be running
GenericLog GenericError 1 2003-05-29
14:46:49 (srbthrd.cpp 44(2445) err=5700041 sys=0) SRB-00041: can't
do SISNAPI handshake
GenericLog GenericError 1 2003-05-29
14:46:49 (srbthrd.cpp 44(2766) err=5700041 sys=0) SRB-00041: can't do
SISNAPI handshake
GenericLog GenericError 1 2003-05-29
14:46:49 (srbthrd.cpp 44(1444) err=5700041 sys=0) SRB-00041: can't do
SISNAPI handshake
GenericLog GenericError 1 2003-05-29
14:46:49 (smimtsh.cpp 25(307) err=5700041 sys=0) SRB-00041: can't do
SISNAPI handshake
TaskCfgExit TaskParamsAtExit 1 2003-05-29
14:46:49 ***********Dumping Parameters for the current task because
of errors**********
Cause
Not an issue.
Solution
For the benefit of reader,
Customer has seen the following intermittent error messages in their SRBroker log files:
GenericLog GenericError 1 2003-06-04 00:30:05 (smimtses.cpp
18(352) err=2100033 sys=0) SMI-00033: The client exited without closing
the SISNAPI connection
GenericLog GenericError 1 2003-05-29 14:46:49 (srbthrd.cpp
44(2445) err=1801033 sys=0) NET-01033: The SISNAPI handshake timed out,
the Siebel Service may not be running
GenericLog GenericError 1 2003-05-29 14:46:49 (srbthrd.cpp
44(2445) err=5700041 sys=0) SRB-00041: can't do SISNAPI handshake
GenericLog GenericError 1 2003-05-29 14:46:49 (srbthrd.cpp
44(2766) err=5700041 sys=0) SRB-00041: can't do SISNAPI handshake
GenericLog GenericError 1 2003-05-29 14:46:49 (srbthrd.cpp
44(1444) err=5700041 sys=0) SRB-00041: can't do SISNAPI handshake
GenericLog GenericError 1 2003-05-29 14:46:49 (smimtsh.cpp
25(307) err=5700041 sys=0) SRB-00041: can't do SISNAPI handshake
After increasing the logging event for SRBroker, we have figured out
that these errors resulted from server shuting down, and can be ignored.
In customer's environment, they have three siebel servers.
Because SRB communicates to all other SRBs on other servers, and
communicates to SRP on the same server, when one of the SRB exits, the
up SRB will normally log the corresponding SISNAPI errors. In the same
way, If on the same server, when SRP exits before SRB , such as server
shuting down, SRB also logs the corresponding SISNAPI error.
Search Keyword: SRBroker, SISNAPI.
Applies to:
Siebel Financial Services CRM - Version 7.8.2.6 SIA [19230] and later
HP-UX PA-RISC (32-bit)
HP-UX PA-RISC (64-bit)
HP-UX Itanium
HP-UX Itanium (32-bit)
One or more Siebel components become unavailable, even if their logs show they are running
SRBRoker log shows errors like
SBL-SRB-00041: Could not send a SISNAPI hello message
Symptoms
In this particular case, the FSMSrvr component registered with port 49179 when the Siebel Server started up
netstat -an | grep 49179
showed
tcp 0 0 127.0.0.1.49179 *.* LISTEN tcp 0 0 *.49179 *.* LISTEN tcp 0 0 127.0.0.1.49179 127.0.0.1.924 ESTABLISHED tcp 0 0 127.0.0.1.924 127.0.0.1.49179 ESTABLISHEDThe Siebel component binds with * (bold),
the binds to localhost (127.0.0.1) are from other software using the same port - in this case, HP Open View.
SRBroker requests don't reach the Siebel component, in this case FSMSrvr.
Note that this is not limited to any specific component name - it can
affect any Siebel Component whose port number from the enterprise log is
used by a different process; another customer for example reported the
same problem for WfProcBatchMgr that suddenly stopped processing
(repeating component) requests.
Cause
HP Open View and also HP WBEM services are using ports already in use by the Siebel Server, leading to a port conflict.
With the Itanium release of HP-UX there was a management utility introduced called
HP-UX Web-Based Enterprise Management (WBEM) Services. This tool is
allocating ports in the same range as the siebel processes, starting at
port 49152. However they bind these daemon processes
named "cimprovagt" only to the loopback adapter which is causing the collision.
Siebel Applications use
SO_REUSEADDR
when opening ports - this is done on purpose to avoid long delays
waiting for a timeout when stopping and starting the Siebel Server
This allows HP Open View binding with localhost (even though the
Siebel Port is already opened and used by the Siebel Application)
and the use of the same port (for different purposes) by two
different applications causes the Siebel component no longer to get its
requests.
Solution
As a quick workaround (that needs to be repeated after every re-boot)
1. Run netstat -an and identify which
root processes are blocking the siebel component ports as described in
the "Symptoms" section.
2. Also execute lsof -i tcp |grep <port number> to identify more root processes blocking siebel component ports as above.
3. Kill the root processes identified this way.
For a permanent solution,
please invoke HP-UX / Open View support,
asking them how Open View or WBEM can be configured to use a port
range that does not conflict with the Siebel Server (which starts using
ports from 49152),
e.g. 49300 and above.
http://forums12.itrc.hp.com/service/forums/questionanswer.do?admit=109447627+1216221381645+28353475&threadId=646982
has more information, put assistance how to configure this would need to come from HP-UX support
HP-UX uses the "ndd" utility program to change tunable IP stack
parameters. The ephemeral ports on HP-UX can be tuned individually for
both TCP and UDP, so there are really two separate ephemeral port
ranges. HP-UX also provides options to change the privileged port range
(ports only processes running with superuser privileges can use).
The good news is that HP-UX uses our recommended port range (49152
through 65535) so it is unlikely you will need to change the range from
the default values.
The example below shows how to query the existing values for the TCP
ephemeral ports, and change the range to 50001 through 61000:
# /usr/bin/ndd /dev/tcp tcp_smallest_anon_port tcp_largest_anon_port
49152
65535
# /usr/bin/ndd -set /dev/tcp tcp_smallest_anon_port 50001
# /usr/bin/ndd -set /dev/tcp tcp_largest_anon_port 61000
# /usr/bin/ndd /dev/tcp tcp_smallest_anon_port tcp_largest_anon_port
50001
61000
Note that if you change the range values, you must do it each time the system boots."
If this cannot be done on the Open View Side,
you may choose to set static ports for every single Siebel Component to avoid port conflicts here.
Keywords (desperate attempt to show this document before the many MR release notes in the knowledge search):
HP-UX port blocked HP-UX PORT USED
hp-ux blocked port
hp-ux blocked port
'hp-ux blocked port'
"hp-ux blocked port"
hp-ux blocked port Siebel
hp-ux blocked port
hp-ux blocked port
'hp-ux blocked port'
"hp-ux blocked port"
hp-ux blocked port Siebel
Applies to:
Siebel System Software - Version 7.8.2 [19213] to 8.2.2.2 SIA[23016] [Release V7 to V8]
Information in this document applies to any platform.
Error Message Area:Server Request Broker - SRB
Version:Siebel 7.8
***Checked for relevance on 27-Feb-2013***
Purpose
This document is intended to provide cause and corrective action
information about Siebel Error Message SBL-SRB-00041: Could not send a
SISNAPI hello message after connecting to the component.
Scope
This document is informational and intended for any user.
Details
Explanation
Could not send hello message to a remote SRB or local batch mode components or local SRProc.
The components may not have been running after the connection was instantiated.
Corrective Action
Check to make sure that:
1) Remote SRB is still running,
2) Batch mode components are still active,
3) Local SRProc is still running.
Applies to:
Siebel System Software - Version: 7.5.3 [16157] and later [Release: V7 and later ]
Information in this document applies to any platform.
Error Message Area:Server Request Broker - SRB
Version:Siebel 7.5.3
Purpose
This document is intended to provide cause and corrective action
information about Siebel Error Message SBL-SRB-00041: can't do SISNAPI
handshake
Scope
This document is informational and intended for any user.
SBL-SRB-00041: can't do SISNAPI handshake
Explanation
Could not send hello message to a remote SRB or local batch mode components or local SRProc.
The components may not have been running after the connection was instantiated.
Corrective Action
Check to make sure that:
1) Remote SRB is still running,
2) Batch mode components are still active,
3) Local SRProc is still running.
אין תגובות:
הוסף רשומת תגובה