Applies to:
Siebel Finance Call Center - Version: 7.8.2.7 [19234] to 8.1.1 SIA [21111] - Release: V7 to V8
Information in this document applies to any platform.
Symptoms
After a server restart, it can happen that the SRProc dispatcher task is terminating itself after 60 seconds.
The following error message can be seen in the SRProc log file:
SBL-SMI-00033: The client exited without closing the SISNAPI connection.
The main SRProc process however continues to run and in srvrmgr status shows as 'running'.
Tasks will remain in queued status and you need to restart the SRProc component to get pending tasks processed.
Cause
Bug 10643087 has been created to address this behavior. There has
been a race condition detected that can cause shutdown of SRProc
process.
Solution
For the benefit of other readers:
Quickfix QF 0765 has been built for the Siebel CRM version 7.8.2.7 Fixpack.
The fix for this issue has been included on the following Siebel CRM maintenance releases and later:
Siebel CRM version 7.8.2.12
Siebel CRM version 8.0.0.7
Siebel CRM version 8.1.1.1
References
BUG:10643087 - [CR#12-1QTP7FD][FR#12-1QTP7FY] SRPROC CRASH/TIMEOUT ON SERVER STARTUP.
Applies to:
Siebel System Software - Version: 7.7.2.3 [18361] and later [Release: V7 and later ]
z*OBSOLETE: Microsoft Windows Server 2003
Product Release: V7 (Enterprise)
Version: 7.7.2.3 [18361]
Database: Microsoft SQL Server 2000 SP4
Application Server OS: Microsoft Windows 2003 Server SP1
Database Server OS: Microsoft Windows 2003 Server SP1
This document was previously published as Siebel SR 38-2794835661.
Symptoms
SBL-DAT-00306, SBL-DAT-00315, SBL-SVR-01014, SBL-SMI-00033, SBL-CSO-01031, SBL-GEN-09103The SRBroker log file often contains the following error message:
SBL-SMI-00033: The client exited without closing the SISNAPI connection.
The eventlog of the server does not show any errors.
The backups of the
database occur at night.
Until now there was no user complaining having lost his
session.
Should we be concerned about this error?
Changes
Cause
Change Request Numbers 10641111 and 10641355.
Solution
For the benefit of other readers:
The Customer had installed and was currently in the process of using the
Siebel Version 7.7.2.3 product release in their Production environment,
when these error messages started to occur with the Server Request
Broker (SRBroker) Server Components:
SisnTcpIp SisnSockError 1 0 2006-01-04
15:00:19 8300: [TCPIP-server] recv() failed for sd=2904 (err=10054 |
An existing connection was forcibly closed by the remote host (peer).)
GenericLog GenericError 1 0 2006-01-04
15:00:19 (smimtses.cpp (350) err=2100033 sys=0) SBL-SMI-00033: The
client exited without closing the SISNAPI connection
Through research and investigation, we discovered that these error
messages could be safely ignored. Product Enhancement Change Request
Numbers 10641771 and 10641272 have been raised to address this SRBroker
error behavior.
We also discovered these error messages occurring here as well :
DBCLog DBCLogError 1 0 2006-03-03 05:37:23 [Microsoft][ODBC Driver Manager] Invalid cursor state
SRPQueryLogEvt SRPQueryError 1 0 2006-03-03 05:37:23 SQL
Error Rc:0 SqlState:24000 Message:[Microsoft][ODBC Driver Manager]
Invalid cursor state
SRPQueryLogEvt SRPQueryError 1 0 2006-03-03 05:37:23 SQL Error Rc:100 SqlState:00000
These messages are related to known product behavior for which Change
Request Numbers 10641111 and 10641355 have already been raised to
address. Refer to the following MOS document for related information:
Keywords: SBL-SMI-00033, Forcibly Closed, SISNAPI, Connection, 12-O6HYF2, 12-HH6SF4, ALERT 953
Applies to:
Siebel System Software - Version: 7.5.3 [16157] and later [Release: V7 and later ]
z*OBSOLETE: Microsoft Windows 2000
Product Release: V7 (Enterprise)
Version: 7.5.3 [16157]
Database: Oracle 9i
This document was previously published as Siebel SR 38-1497603097.
Symptoms
SBL-SMI-00033
SBL-SMI-00033. The client exited without closing the SISNAPI connection.
We have checked Support web for this error, which suggests no specific way to resolve.
We have tried to stop and restart the Services on our main Server, but this has not fixed the issue.
Can you suggest any other way to rectify this issue?
Solution
The customer had a morning batch process on their Siebel Server and
observed many Server Request Broker (SRB) tasks that exited at around
the same time (anywhere up to 200 requests in this batch).
The customer restarted the Siebel services on their main server, but this did not fix the exiting SRB tasks.
The
last time the Siebel Server machines were re-booted was about one month
ago: the machines were re-started which resolved the behavior.
Siebel
Technical Support requested the Windows server's application and system
event logs, in order to review these to obtain a better understading of
the behavior:
The Siebel Servers are shutdown every night for
the database to be backed up. It was noted that 22 seconds after the
database backup at 04:00, a siebmtshmw.exe process (a multi-threaded
server component) raised an exception at 04:00:22 reporting the
following error:
---
10/09/2004 04:00:22 Siebel
Application Error Printers 1002 N/A S7OFS1 "The
description for Event ID ( 1002 ) in Source ( Siebel Application )
cannot be found. The local computer may not have the necessary registry
information or message DLL files to display messages from a remote
computer. The following information is part of the event: Exception
0xc0000005 at 0x00154030
Thread: 0x00000bf4, Process 0x00001238
---
This
means the component crashed. We believed that this was the SRB process.
The call stack was included in the event log (but did not show any
useful information). This was the first occurence of this crash type. It
occured 5 times between this initial occurence and 10:07:59 on the same
date. This type of crash did not occur prior to the 10th of September,
nor did it occur subsequently.
The error code "Event ID 1002"
means that the component experienced a "Disconnect error", which would
make sense in that the database was being backed up. It seemed that the
component had difficulty re-establishing a connection with the database
after the backup. We do not know why the component could not
re-establish a connection.
The customer was satisified with this analysis.
Applies to:
Siebel System Software - Version: 7.7.2.2 SIA [18356] and later [Release: V7 and later ]
z*OBSOLETE: Microsoft Windows 2000
Product Release: V7 (Enterprise)
Version: 7.7.2.2 [18356] Cons Goods
Database: Oracle 9.2.0.4
Application Server OS: Microsoft Windows 2000 Server
Database Server OS: Compaq Tru64 UNIX
This document was previously published as Siebel SR 38-2942604721.
Symptoms
SBL-SMI-00033, SBL-ADM-09217Dear Support,
we have problems to set up the Admin Notification on the Enterprise level
via Email.
I already read in the Siebel Bookshelf 7.7 (configuring Siebel Servers, page
76-79) and also in SR# 38-1486557451but I still recieve errors.
We also set up an order
confirmation via Email with the same Servername and Serverport as we used for the Admin Notify
and that is working fine.
Can you please help?
Please see the attached
files.
1 Word Document with 3 Hardcopies showing different Screens/Parameters
2 log
files from our QA system
(AdminNotify_38.log,
POP3SMTP_1B2C_1_1_43FADED2_808E282E.log)
Best Regards
Cause
Configuration/ Setup
Solution
Message 1
For the benefit of other users:
Original Issue:
Customer configured the Admin Notification component on the Enterprise
level as documented in the Siebel Bookshelf. While testing the
functionality the following error messages were encountered in the
AdminNotify_xx.log file:
- SBL-ADM-09217: Error occurred in invoking the notification handler in
dll [ssemailntfy] for doing notification configured in named subsystem
[AdminEmailAlert] for component [SiebSrvr]
- Socket error 10053: An established connection was aborted by the software in your host machine.
- Unable to connect socket to port 25 on remote host crw-001.ho.u1403.unilever.com
- Socket error 10053: An established connection was aborted by the software in your host machine.
Solution:
After further investigation and reviewing all configuration steps for
the Admin Notification component, it was found that behavior was not
related to any incorrect configuration of the component.
Further investigation of the error messages logged in the AdminNotify log file revealed the following:
- An established connection was aborted by the software in your host machine.
- Error 10053 means that an established connection has been dropped.
...
Message 2
...
The first part of the error message \'software in your host machine\'
that is referred to is actually \'Winsock\' - the TCP/IP component of
Windows. The \'protocol error\' referred to in the second text is the
TCP protocol, not POP3 or SMTP, etc protocol.
10053 errors are actually quite rare usually, but there are a couple of
cases which can cause them; It could be a problem caused by an
antivirus software. Some virus scanners have been known to cause these
errors.
After excluding the Siebel component from the Antivirus software, Admin
Notification alerts were sent out correctly through Emails on port 25.
Keywords:
Socket error 10053; An established connection was aborted by the
software in your host machine; Admin Notifictaion; System Alert;
Thanks and Regards,
Applies to:
Siebel System Software - Version: 7.7.2.3 SIA [18361] to 8.1.1.4 SIA [21225] - Release: V7 to V8
IBM AIX on POWER Systems (64-bit)
Product Release: V7 (Enterprise)
Version: 7.7.2.3 [18361] NLD Fin Svcs
Database: Oracle 8.1.7.4
Application Server OS: IBM AIX 5L 5.2
Database Server OS: IBM AIX 5L 5.2
This document was previously published as Siebel SR 38-2424543581.
*** Checked for relevance on 04-May-2011 ***
Symptoms
SBL-SMI-00033We have 2 siebel servers in our enterprise, one running on AIX which hosts the Application OM's,
and one on W2K which host Communication Server for CTI.
Upon start-up of our siebel
server(AIX), the SRProc component raises a SBL-SMI-00033 error message. This occurs consistantly
every time the Siebel server is restarted. If I then manually shutdown and restart just the
SRProc component (via the UI), then this component does not raise this error. I also notice that
upon startup of the 'Server Request Processor' component shows one open task (via server manager
UI). After manual re-start of 'Server Request Processr', there are 2 open tasks.
Please
advise what the casue of SBL-SMI-00033, and how we can correct it
Cause
Environment specific
Solution
We tried to see if this was port conflict issue, it was not. However we
found that the Encryption Type is RSA for the SRPRoc. we requested to
set it to None for SRProc and SRBroker as this typically applies to AOM.
We also ensured that after changing the parameter and starting the
server it was set to None
In customer's environment RSA encryption had been enabled at the
Enterprise level, so they Disabled encryption for SRproc and SRBoker.
This helped customer resolve the behavior.
Applies to:
Siebel System Software - Version: 7.7.2.6 [18372] and later [Release: V7 and later ]
z*OBSOLETE: Microsoft Windows 2000
Product Release: V7 (Enterprise)
Version: 7.7.2.6 [18372]
Database: Microsoft SQL Server 2000 SP3
Application Server OS: Microsoft Windows 2000 Server SP 4
Database Server OS: Microsoft Windows 2000 Server SP 4
This document was previously published as Siebel SR 38-3197311343.
Symptoms
SBL-OSD-00098, SBL-SMI-00033We just had the following error in our Production Siebel
Task 12337 of component SRBroker
has ended with error code 2100033 error string SBL-SMI-
00033: The client exited without
closing the SISNAPI connection
This type of error happened frequently when we were 7724
level. Now we are patched up to 7726(11-08-206) and we understand that this would no longer
happen with 7726.
We have crash_xxx.txt created with this error. No FDR log was created.
Cause
Configuration/ Setup
Solution
Message 1
For the benefit of other readers.
Customer had crash in FINSObjMgr_enu with the following information:
1. Error message in enterprise log:
ServerLog ProcessExit 1 0 2006-11-22
10:09:19 FINSObjMgr_enu 25638 SBL-OSD-00098 Process exited with
error - Internal: The process exited abnormally and the Operating
System could not get the exit code
2. This call stack generated from UserDump, because there was no crash or *.fdr file created:
sscfcmn!CSSLocalStringManager::GetLocalString+0x1e
sscfcmn!CSSObjectBase::GetLocalString+0x1f
sscfcmn!CSSObjectBase::IsLocalString+0x26
sscfdm!CSSQuery::UsesTable+0x493
sscfdm!CSSQuery::UpdateFieldSearchSpec+0x6a1
sscfdm!CSSQuery::Parse+0xf1b
sscfdm!CSSQuery::Parse+0xef4
sscfdm!CSSQuery::ParseFieldExpr+0xd63
sscfdm!CSSQuery::GetPhysText+0x47
sscfdm!CSSSqlObj::AddSqlWhereClause+0x336
sscfdm!CSSSqlObj::AddSqlParts+0x208
sscfdm!CSSSqlObj::Execute+0x78a
3. The corresponding FINSObjMgr_enu.log log file has the following info:
ObjMgrBusServiceLog InvokeMethod 4 0 2006-12-14
10:04:28 Begin: Business Service 'Data Validation Manager' invoke
method: 'Validate' at 30c19ad0
ObjMgrBusCompLog Create 4 0 2006-12-14 10:04:28 Begin: construct BusComp "FINS Validation Rule Set" at 31cb33c0
ObjMgrBusCompLog Debug 5 0 2006-12-14 10:04:28 BusComp
FINS Validation Rule Set has 22 total, 7 NJS, 2 FA, 2 LS, and 0 SeqObj
metadata fields.
ObjMgrBusCompLog Create 4 0
ObjMgrBusCompLog Create 4 0 2006-12-14 10:04:28 End: construct BusComp "FINS Validation Rule" at 31cbd070
ObjMgrBusCompLog Create 4 0 2006-12-14 10:04:28 Begin: construct BusComp "FINS Validation Action" at 31cbe588
ObjMgrBusCompLog Create 4 0 2006-12-14 10:04:28 End: construct BusComp "FINS Validation Action" at 31cbe588
ObjMgrBusCo
4. Errors seen in SRBroker and in SRProc were just a consequence of the crash in FINSObjMgr_enu.
Resolution.
With the information above, it was found that there was a DVM process
triggered on the PreWriteRecord of the Service Request BC. After
disabling it, the crash did not happen anymore.
Thank you and kind regards,
Siebel Technical Support
Applies to:
Siebel System Software - Version: 7.7.2.2 [18356] and later [Release: V7 and later ]
z*OBSOLETE: Microsoft Windows Server 2003
Product Release: V7 (Enterprise)
Version: 7.7.2.2 [18356]
Database: Oracle 9.2.0.6
Application Server OS: Microsoft Windows 2003 Server SP1
Database Server OS: HP-UX 11i
This document was previously published as Siebel SR 38-2879423618.
Symptoms
SBL-SVR-01014, SBL-SMI-00033, SBL-SMI-00049, SBL-CSO-01031, SBL-GEN-09103In our production environment the SRBroker component is using massive amounts of memory. We have
a maximum of 100 brokers running, and they are currently using up to 15gb of ram.
Is it
normal for the SRBroker to use this much memory? Is there some way we limit this memory
usage?
The server this component is running on has 8gb of physical ram.
I have
exported the configuration parameters for the SRBroker and attached them for your
reference.
Our production environment went live today, so this is a big issue for us. We
have already had to restart the server once, which has a negative impact on our call centre
users.
Thanks,
Cause
Product Enhancement Change Request Number 12-1BYX33J
Solution
Message 1
For the benefit of other readers :
The Customer was currently experiencing some Server Request Broker
(SRBroker) error behavior, whilst running some specialised Workflow
Processes using their Siebel Version 7.7.2.2 product release.
Specifically, the SRBroker Components were consuming a large amount of
available memory (around 15Gb RAM) causing their SRBrokers to become
"maxed out" and the users would then be experiencing some performance
challenging error behavior.
Following on from our examination of the Server Request Broker settings,
we discovered that their Siebel Object Manager parameter settings had
been changed and were different from the ones originally specified by
our Expert Services (ES) Division during their PRR (Production Readiness
Review). For example: their EAI (Enterprise Application Integration)
Object Manager MaxTasks Server parameters were set to 50, whereas
originally they had been set to 20. We were also concerned that the
Customer was running 100 SRBrokers on one Enterprise Application Server
machine, whereby the Siebel recommendation would be to run 1 SRBroker
with 100 Max MT Server Tasks instead.
We also suggested that the Customer run with the Siebel "Recycle" Factor
for their Object Manager Settings - addtional information can be
acquired from reading through Siebel Version 7.7.2.x Bookshelf >
Siebel System Administration Guide > Appendix A: Siebel Server
Components and Parameters > Generic Parameters > Parameters :
<Continued ...>
Message 2
Recycle Factor. This parameter allows an alternate method to managing
resources through the use of a rolling shutdown and restart of component
processes. The Siebel Server components, however, do not require the
recycling of processes. Use this parameter to remedy your application
only if excessive memory usage appears to exist.
The Customer also required some information regarding the use of the
Siebel Server Scheduler ? I discovered this information for them :
The Siebel Server Scheduler (SrvrSched) is a Component Definition, and
therefore runs as a Component on every Siebel Server. It is a
multi-threaded component. However, it is advisable to only run 1 per
Siebel Server. The default settings for a multi-threaded component are:
MaxTasks=20
MinMTServers=1
MaxMTServers=1
As such, you will then see that MaxTasks = 1 defined at the Component
Definition level for "SrvrSched". This will ensure that 1 process, with 1
Server Task is loaded per Siebel Server. Since it exists as a
background component on each Siebel Server which Schedules Siebel Server
job execution, details can be then captured by increasing event Log
Levels.
Under normal and most circumstances, it is advisable to just leave this
alone. As it is internal task that forms part of System Task Management
and one of the first processes loaded when the Siebel Server is actually
started and is used to spawn the other components.
<Continued ...>
Message 3
I raised Product Enhancement Change Request Number 12-1BYX33J to allow
for "monitoring" of these Siebel Server Scheduler (SrvrSched) Component
Task Parameter settings. I also raised Documentation Enhancement Change
Request Number 12-1C06PMF to have this Siebel Version 7.7.2.x Bookshelf
> Siebel System Administration Guide updated with additional
information surrounding the use of this Siebel Server Scheduler.
Keywords: SRBroker, Server, Request, Settings, MT, Task, Parameters, Asynchronous, Monitor, Scheduler, Components
Applies to:
Siebel System Software - Version: 7.5.2.214 SIA [16066] and later [Release: V7 and later ]
z*OBSOLETE: Microsoft Windows 2000
Product Release: V7 (Enterprise)
Version: 7.5.2.214 [16066] Fin Svcs
Database: Oracle 8.1.7.4
Application Server OS: Microsoft Windows 2000 Server SP 3
Database Server OS: Sun Solaris 2.8
This document was previously published as Siebel SR 38-1094804267.
Symptoms
SBL-EVT-01012, SBL-SVR-00005, SBL-SVR-00029, SBL-SCC-00025,
SBL-SVR-01045, SBL-SCM-00018, SBL-SMI-00033, SBL-SRB-00061,
SBL-SRB-00041, SBL-GEN-05009, SBL-ADM-02044, SBL-ADM-02049Hello,
I have just finished upgrading from 7.5.2.214 SIA [16066] to 7.5.3 SIA
[16157].
Our configuration is:
- 1 Unix server CLSSS22: OS Solaris 2.8 with the
Entreprise Server et 1 Siebel Server 'CRMR'
- 1 Windows 2000 Service Pack 4 Server
'xxxSA2048'
- Oracle version 9.2.0.2
When I go on the server admin screens, I can see
that the server server 'xxxSA2048' is in status "Echec de la connexion" (connexion failed). If i
click on this server, i receive the following error "SBL-ADM-02044: Aucune connexion trouvée sur
les serveurs actifs.".
By server manager, i have the following
message:
"decibel@clsss22:/appsiebel/siebel/siebsrvr/bin$ srvrmgr /e CRMR /g CLSSS22:2323 /u
SADMIN /p
SADMIN
Connected
to 1 server(s) out of a total of 2 server(s) in the enterprise
srvrmgr> list
server
SBLSRVR_NAME HOST_NAME
INSTALL_DIR SBLMGR_PID
SV_DISP_STATE SBLSRVR_STATE
START_TIME END_TIME
SBLSRVR_STATUS
------------
--------- -------------------------- ---------- ------------- ------------- -------------------
-------- ------------------------------
CRMR clsss22 /appsiebel/siebel/siebsrvr
15564 Running
Running 2003-10-07
11:22:27 7.5.3 [16157]
LANG_INDEPENDENT
xxxsa2048 xxxsa2048
E:\sea752\siebsrvr
Connect failed"
Thank you for your help
Cause
Configuration/ Setup
Solution
Message 1
For the benefit of other readers, the 'Connect failed' error was caused
by a network problem. The new Windows 2000 Server 'xxxSA2048' (masked)
was not declared in the DNS server. After setting the correct value to
DNS and restarting the machine, the connection to server was
successfully established.
The error messages received were as follows in the Siebel Server Log files.
SBL-SCC-00025; SBL-SVR-00029; SBL-ADM-02049; SBL-ADM-02044;
SBL-EVT-01012; SBL-SVR-00005; SBL-SVR-01045;
SBL-GEN-05009;SBL-SMI-00033; SBL-SRB-00061; SBL-SRB-00041; SBL-SCM-00018
The following Supportweb Knowledge items were also suggested:
FAQ 1323 which discusses how to troubleshoot error ADM-02044.
FAQ 1187 which discusses how to troubleshoot error ADM-02088.
FAQ 1399 which discusses how to troubleshoot error NET-01003.
-Siebel Technical Support
Keywords: DNS Server, Connect Failed, list server, SBL-SCC-00025,
SBL-SVR-00029, SBL-ADM-02049, SBL-ADM-02044, SBL-EVT-01012,
SBL-SVR-00005, SBL-SVR-01045, SBL-GEN-05009, SBL-SMI-00033,
SBL-SRB-00061, SBL-SRB-00041, SBL-SCM-00018
Applies to:
Siebel CRM - Version: 7.5.3 [100] to 8.1.1.7 [21238] - Release: V7 to V8
Information in this document applies to any platform.
Product Release: V7 (Professional)
Application Server OS: Microsoft Windows 2000 Server SP 4
Database Server OS: Microsoft Windows 2000 Server SP 4
Symptoms
It was reported that there were problems using drag drop
functionality in the Siebel application. When the user was trying
to save an attached document, the system was displaying the following
error message:
Session
Warning: 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.After this error, the user is usually logged out of the application.
The issue was only present in the thin client and could not be reproduced in the dedicated client.
The same error was observed in the thin client using both DB authentication and ADSI authentication.
The following messages were displayed in the SWE logs:
ProcessPluginRequest ProcessPluginRequestError 1 0 2006-04-18
17:15:22 5116: [SWSE] RPC coming in without a user session
ProcessPluginRequest ProcessPluginRequestError 1 0 2006-04-18
17:15:22 5116: [SWSE] Failed to obtain a session ID. NOT OK
ProcessPluginRequest ProcessPluginRequestError 1 0 2006-04-18
17:15:22 5116: [SWSE] Set Error Response (Session: Error: 00065535
Message: NOT OK)The following error messages may also be seen for the end user or in the logs related to this issue:
SBL-UIF-00401,
SBL-SCR-00141, SBL-DAT-00215, SBL-DAT-00712, SBL-SVR-01051,
SBL-SCM-00022, SBL-SMI-00033, SBL-NET-01023, SBL-BPR-00125,
SBL-BPR-00151
Cause
The cause of this issue was determined to be an underscore "_" character in the naming of the servers.
Solution
The workaround for this issue is to use the IP address of the server instead of the server name.
Document 477993.1 has additional information regarding problems using a dash/hyphen in the Siebel Server Name.
Document 477993.1 was previously referred to as Alert 1067.
References
NOTE:477993.1 - Siebel Server Failures Due to Hyphen Character in Machine Hostname and in the Siebel Server Name
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,
Applies to:
Product Release: V7 (Enterprise)
Version: 7.5.3 [16157]
Database: Microsoft SQL Server 2000 SP3
Application Server OS: Microsoft Windows 2000 Advanced Server
Database Server OS: Microsoft Windows 2003 Server
This document was previously published as Siebel SR 38-2898910561.
Symptoms
We have recently applied the 7.5.3.14 patch to our 7.5.3 installation. We have patched both our DEV and TEST instances.
In our TEST environment only, the only environment with Communications
Management enabled, we are seeing new log files for smart answer and
SRBroker being created about every couple seconds. This has only been an
issue since the application of the 7.5.3.14 patch. The smart answer
files show an error of "Smart Response module is not licensed" and the
SRBroker files show an error of " [TCPIP-server] recv() failed for
sd=2088 (err=10054 | A existing connection was forcibly closed by the
remote host (peer).)
GenericLog GenericError 1 2006-02-03 22:50:53 (smimtses.cpp
18(352) err=2100033 sys=0) SBL-SMI-00033: The client exited without
closing the SISNAPI connection"
Do you have any suggestions to resolving this, other than setting the
smart answer component to disabled? How can I verify our license
contains this module for comm mgmt?
Why are these log files being generated only AFTER applying the patch to
the application? it was running with no issues before the patch.
Thanks
Solution
Message 1
For the benefit of others:
After a recent upgrade, the smart answer functionality of communications
server seemed to have been disabled. It was later discovered that the
customer was not licensed for this functionality. However, the issue
became stopping the logging from occurring, for a disabled component.
To ensure logging is inactive for a component:
There are a couple of areas to check, to make sure that logging is no longer active...
First, ensure that the component is completely inactive:
Administration - Server Management > Components > Smart Answer Manager
Please make sure that the component is both offline and Shutdown
Next: Verify the logging event levels...
Administration - Server Configuration > Components > Smart Answer Manager > Events (Tab)
Please make sure that all of the event levels are 1 or zero. 1 is the
default, and will only produce log entries for component Errors. 0 will
only produce errors for Fatal events. You can also check the other
components, such as SRBroker and CommMgr. Specifically, if there are any
components where you have increase event logging, please return those
to 1.
Best regards,
Siebel Technical Support
Keywords: continuing continuous logging wont stop repeating logs
אין תגובות:
הוסף רשומת תגובה