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

Date:

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.
  1. Check the Object Manager listener log file and confirm if it contains the SBL-SMI-00006: Internal: SISListen failed error.
  1. 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
    1. 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,