SBL-SCB-00015: The component is down or not available

Applies to:

Siebel System Software - Version: 7.0.4 [14068] and later   [Release: V7 and later ]

Generic Windows

Area(s):System Administration

Release(s):V7 (Enterprise), V7 (Professional)

Database(s):All Supported Databases

App Server OS(s):HP-UX, Solaris, AIX

Latest release tested against:V7 (Enterprise)

Keywords:Solaris, accept, failed, shutdown, signal, SIGPIPE, core, SBL-SMI-00006, hang, logout, users



This document was previously published as Siebel Alert 1206.

Description

Process
signals are used for the purpose of interrupting normal process
execution and informing it about a certain error condition that needs
some recovery activity by a process or by a certain thread of a process.

These signals could be generated by the operating system, or could be invoked via C/C++ code.

Examples:

• A
  custom C++ application (library) is invoked from a Call Center Object
  Manager user or thread via the Siebel eScript SELib mechanism. The
  library connects to a process or files via named pipe mechanism. A
  networking problem or timeout occurs and the communication pipe is
  broken unexpectedly. The operating system issues a SIGPIPE signal to the
  process to inform it about the broken connection.

• A
  custom C++ application (library) is invoked from a Call Center Object
  Manager user or thread via the Siebel eScript SELib mechanism. The C++
  application contains code that sets a specified time it wants to perform
  an operation or wait on a particular resource. It uses a SIGALRM
  signal/handler routine to achieve this. After the time period is elapsed
  a SIGALRM process is triggered.

In
both of these cases, the signals are intended to inform the thread
which was performing a particular request to stop (interrupted) and then
to execute a particular signal handler routine.

However,
these signals could also intercepted by the listener thread (thread# 1)
which is responsible for the startup and shutdown of the entire
process. When such a signal is received, the process may shutdown
resulting in all the users who are logged into this process to have to
re-login.

Bug 10501186 has been logged to address this product defect.

Likelihood of Occurrence

You
may encounter the behavior in this Alert if you are running the Siebel
Business Application Server versions 7.7.x or 7.8.x on any
UNIX platform.

Possible Symptoms

Below are different symptoms that may be reported if you are encountering this behavior:

• The browser displays the error message for new users trying to login:

SBL-SWP-00121:
The server you are trying to access is either busy or experiencing
difficulties. Please close the Web browser, open a new browser window,
and try logging in again.

• The following errors are reported in the SCBroker log file:

GenericLog     
GenericError    1       0       2005-11-14 10:50:14     (scbcomp.cpp
(416) err=7100015 sys=0) SBL-SCB-00015: The component is down or not
available on this server

GenericLog     
GenericError    1       0       2005-11-14 10:50:14     (scbcomp.cpp
(235) err=7100015 sys=0) SBL-SCB-00015: The component is down or not
available on this server

GenericLog     
GenericError    1       0       2005-11-14 11:06:18     (scbcomp.cpp
(822) err=7100011 sys=0) SBL-SCB-00011: Failed to connect to pipe
(SEBL_11_5316) on process 5316.

GenericLog     
GenericError    1       0       2005-11-14 11:06:18     (scbcomp.cpp
(416) err=7100011 sys=0) SBL-SCB-00011: Failed to connect to pipe
(SEBL_11_5316) on process 5316.

• Depending
  on the Siebel version you are using, you may encounter either a core
  dump or the process being frozen in the shutdown state. In the latter
  case you will need to kill it from the shell to get the process
  released.  Here is an example of an output from a process that is hung
  with the following call stack:

4017:   siebmtshmw /siebel/osprd/siebsrvr/admin/osPRDent.siebsrvr1.shm 11 6150

-----------------  lwp# 1 / thread# 1  --------------------

 7daa58f4 lwp_park (0, ffbfeae8, 0)

 7daa2b9c cond_wait_queue (ba25f0, 7dab8b48, 0, 0, 7d790000, 7dab8000) + d4

 7daa3114 cond_wait_common (0, ba25d8, ffbfeae8, 0, 0, 437afb47) + 1d8

 7daa35a4 _cond_timedwait (ba25f0, ba25d8, ffbfec18, 0, 0, 0) + 1f0

 7daa35d8 cond_timedwait (ba25f0, ba25d8, ffbfec18, 0, 0, 0) + 18

 7daa3618 pthread_cond_timedwait (ba25f0, ba25d8, ffbfec18, 10624c00, 0, 0) + c

 7fa1291c __1cMosaWaitEvent6Fpvi_i_ (ba25d0, 1388, 0, 0, ba25d8, 0) + 188

 00031600 __1cNsmiMainThreadIShutdown6M_v_ (695f38, a0, 1, 86070, 688, 400) + 50

 0002f7c8 __1cNsmiMainThreadIMainLoop6M_i_ (695f38, 1b7740, 0, 0, 7bd3080, 5e) + d00

 0002a754 wmain    (9, 12f100, 0, 0, 0, 0) + 274

 0005dd60 main     (ffbff174, 86070, ffbff19c, 7e157380, 74c, 400) + 94

• The object manager’s listener thread session log file contains the following error:

SisnTcpIp     
SisnSockError     1     0     2005-09-09 12:26:29     1:
[LOCALTRANS-server] accept() failed during get conn request (error=9602,
sys=4)

GenericLog    
GenericError      1     0     2005-09-09 12:26:29     (smimtsrv.cpp
(1538) err=2100006 sys=0) SBL-SMI-00006: Internal: SISListen failed

You
can identify the listener thread session log file by searching for the
pattern “ 1 “ in the header line of all log files by running the
following command:

head -1 *.log | grep “ 1 “

The output should return something like the following:

1021 2005-10-05 20:55:19 0000-00-00 00:00:00 +0200 00000000 001 003f 0001 09 FINSObjMgr_deu 16434 23184 1

Workaround or Resolution

If you are running on Siebel Maintenance Release 7.7.2.x, the above behavior has been fixed in Siebel Fix Pack version 7.7.2.5.

For other Siebel versions, you should perform the following analysis:

1. Check the SCBroker log file and confirm if it contains the SBL-SCB-00011 error.

2. Check the Object Manager listener log file and confirm if it contains the SBL-SMI-00006: Internal: SISListen failed error.

3. Check for the following:

1. If the process is hanging, run the command below and see if the call stack matches the one documented in this Alert.

pstack <PID_OF_OM>

          or

2. If
   the process has generated a core dump, run the command below and see if
   the thread# 1 is showing on the top of the stack trace as documented
   above.

pstack core

If
the errors plus call stack matches all three scenarios, then you should
apply the Siebel Fix Pack version 7.7.2.5 on top of Siebel Maintenance
Release 7.7.2.

If
you experience similar behaviors described in this Alert, but all the
above 3 scenarios do not match, then please log a new service request.
Provide all the relevant Siebel log files, pstack of hung processes or
crashed processes (core file).

For additional information about troubleshooting Server components behaviors on UNIX, refer to Document 477520.1 and Document 478027.1.

Maintenance Release Number

Please click on the link below to view the current status of the Change Request and associated Fix Requests:

Bug 10501186 has been fixed on version 7.7.2.5 and 7.8.2.2

Applies to:

Siebel CRM - Version: 8.1 [21039] and later   [Release: V8 and later ]

Information in this document applies to any platform.

Server busy error with custom OM -ACSWMTObjMgr_enu

Symptoms

When try get the Siebel login by using custom component - customer Object Manager -ACSWMTObjMgr_enu ,we get following error



http://10.203.168.143/acswmt_enu/start.swe?" URL getting the following error message:

The server you are trying to access is either busy or experiencing
difficulties. Please close the Web browser, open a new browser window,
and try logging in again.[23:24:13]



In OM logs, these errors were found



 2009-10-11 23:07:37 Login failed for Login name : anonemp

 2009-10-11 23:07:39 (ctxtmgr.cpp (4504)) SBL-SVC-00208: Please login first



In SWSE logs, these errors where found



2009-10-11 22:53:16 ( (0) err=4653071 sys=0) SBL-SCB-00015: The component is down or not available on this server



2009-10-11
22:56:21 (smconn.cpp (283) err=1180866 sys=2321) SBL-NET-01218: The
connection was refused by server hcmblysun004a. No component is
listening on port 2321.



 2009-10-11 22:56:21 (ssmsismgr.cpp (773) err=3670019 sys=0) SBL-SSM-00003: Error opening SISNAPI connection.

 2009-10-11 22:56:21 (ssmsismgr.cpp (1761) err=3670022 sys=0) SBL-SSM-00006: Error while sending message to server.

 2009-10-11
22:56:21 (smconn.cpp (283) err=1180866 sys=2321) SBL-NET-01218: The
connection was refused by server hcmblysun004a. No component is
listening on port 2321.

Changes

Created custom Object manager -ACSWMTObjMgr_enu

Cause

Incorrect value for Siebel Repository File parameter





.

Solution

Setting the correct value for Siebel Repository File parameter resolved this issue.

Applies to:

Siebel System Software - Version: 7.8.2.2 [19219] and later   [Release: V7 and later ]

z*OBSOLETE: Microsoft Windows Server 2003

Product Release: V7 (Enterprise)

Version: 7.8.2.2 [19219]

Database: Oracle 9i

Application Server OS: Microsoft Windows 2003 Server SP1

Database Server OS: Sun Solaris 9



This document was previously published as Siebel SR 38-3035052921.

Symptoms

SBL-SVR-01015, SBL-SVR-01043, SBL-SMI-00033, SBL-NET-01034, SBL-NET-01033, SBL-ADM-01044, SBL-SCB-00015, SBL-SCB-00011Hi,



Each night a cold DB backup is taken on each environment. This is affecting a number
of components on the Siebel server:



Transaction Processor

Transaction
Merger

Transaction Router

Server Tables Cleanup



These components need to be
restarted each morning as the backup is affecting them. I decided to use scripts to shutdown the
siebel server 15 mins before backup is taken and another to restart it in the morning. I have
tested these script on one environment and this works fine. On another environmnet the shutdown
script appears to hang (i.e batch job does not complete). All the parameters are correct as the
command would not run otherwise. I have attached the script and the log files at the time it
executed (01:45). As you can see from the log file at 06:00 created after the startup script is
executed, the server is still shutting down. Can you please inform me what the issue
is?



Kind regards

Cause

Configuration/ Setup

Solution

Message 1

For the benefit of other readers:



The customer's script:



D:\sea78\test\siebsrvr\BIN\srvrmgr /g UKGateway /e siebtest /s SiebTest1 /u sadmin /p password /c "shutdown appserver SiebTest1"



In review of the customer's component log files, we could see that there
was a problem with one or more components shutting down. As stated in
SupportWeb SR 38-1147657941 [Siebel Servers stick in "Shutting down"
state], the "shutdown appserver" command issued from the Server manager
command-line is a synchronous process, thus the command will block until
all tasks in the server have exited. There could be a problem stopping
one or more components, caused either by the components themselves, or
caused by the synchronous nature of the shutdown process (ie. one
component is waiting on a response from another component, or the Siebel
server - that may have already been shutdown).



The customer was recommended to use the Windows command, net stop. The net stop command is used as follows:



net stop <service>



For example:



net stop SiebSrvr



Which would stop the service called SiebSrvr.



Assuming you do not have any problem stopping your Siebel Server service
using the Windows' Services utility, then you should not experience a
problem with using the net stop command to stop the Siebel Server
service. You can schedule the command using the Windows command, at.



This information resolved this for the customer.



Regards,