|
|
This chapter provides maintenance and troubleshooting information for CPC. This includes the following:
The Administrator must perform regular CPC maintenance. CPC maintenance activities include:
A UNIX backup utility should be used to periodically backup the Server installation directory.
Transactions must be manually purged from the system. This can be done from the Transaction Manager or through the FTI.
During the operation of CPC, log and other bookkeeping files may be created. these are usually preserved by the system, since they are useful in debugging problems. However, in order to prevent unbounded growth of the file system, these files should be manually purged.
A prototype cron file which handles this task is provided in $CCP_REL/mng/template/activator.cron. This should be copied to $CCP_REL/mng/utility and edited according to the comments contained inside.
The administrator must perform regular Informix DBMS maintenance. Please see the Informix vendor documentation for details. Activities include:
The Informix database has a query optimizer which improves performance of queries by selecting optimal or near-optimal data access paths. This selection is based on an understanding of the data distributions in the tables being referenced. Note that these distributions are only updated manually. Since this can be a relatively expensive operation, this should only be done at the "right time". Specifically, this should be done:
A sample script which will update the distribution is:
#!/bin/ksh if [[$#!=1]] then echo "usage:'basename $0' dbname" exit 1 fi $INFORMIXDIR/bin/dbaccess $1<<EOF update statistics medium for table; update statistics for procedure; EOF exit 0
This section describes the procedures for CPC backup and restore. Two types are described: offline and online. Offline backup and restore requires that CPC be shut down before backup, whereas online backup and restore does not.
Offline backup captures a complete image of the CPC system and thus permits a complete restore. The procedure requires that the original installation disks as well as all patches be available to permit the system to be restored.
There are various areas that require backup:
In all cases, ensure that the CPC server is shutdown before performing backup. The Informix database server should not be shutdown. Note that a file backup utility such as tar(1) or cpio(1) must be used to backup UNIX-based files. These should always be executed so as to preserve links, for example,
This backup should be done while signed on as the Informix administrator, informix. There are 2 sets of files that need to be backed up: administrative files and the databases.
Informix Administrative Backup
The following files from $INFORMIXDIR/etc should be backed up using a file backup utility:
Informix Database Backup
There are several Informix utilities which can be used to perform backup. These are:
These are fully described in the Informix manuals Archive and Backup Guide (On-Archive and ontape) and Backup and Restore Guide (On-Bar). This section describes the use of the simplest of these utilities--ontape. The other programs are more complex to use but provide additional features such as unattended operation, parallel backup, online tracking of backup sessions and storage device independence.
During system installation, ensure that the following attributes are correctly set in the $ONCONFIG file.
| ONCONFIG Parameter | Value |
TAPEDEV | Name of tape device to be used for backup. To simplify system administration, this device should be a symbolic link to the actual device used for backup. Note that a Level-0 archive (see below) must be performed when ever this parameter is changed. |
TAPEBLK | Tape block size (in kBytes) used for archiving. This is device specific and should be obtained from the UNIX system administrator. |
TAPESIZE | Tape size in kBytes. This value is media specific and should be obtained from the UNIX system administrator. |
LTAPEDEV | Set to /dev/null. |
LTAPEBLK | This can be set to any value. |
LTAPESIZE | This can be set to any value. |
Informix supports the concept of levels when archiving. These are:
| Archive Level | Description |
|---|---|
Level-0 | Entire Informix Server |
Level-1 | All data changed since the last Level-0 archive. |
Level-2 | All data changed since the last Level-1 archive. |
Clearly, the higher the level of archive, the faster a backup will complete. However, during a restore more tapes will need to be read to obtain the latest database image. A reasonable backup schedule might be to:
Before backup, ensure that there is a dedicated terminal/xterm window available to permit the operator to interact with ontape. For example, if a tape fills and needs to be changed, then the operator will be prompted on this session to do so.
Each tape must be labelled after archiving with:
To perform a backup:
Step 2 Load a write-enabled tape into the tape device identified by the ONCONFIG parameter TAPEDEV.
Step 3 Ensure the tape is rewound by executing:
mt -t tapeDev rew
where tapeDev is the tape device.
Step 4 Execute:
ontape -s -L archiveLevel
where archiveLevel is the archive level (0, 1 or 2).
This will create the requested archive. The operator is expected to respond to the prompts as required.
The following directories/files should be backed up using a file utility:
| Directory/File | Contents |
|---|---|
$CCP_REL/mng/utility/syccpenvsetup | Contains the installation-specific information useful for reinstallation. |
$CCP_REL/mng/utility/syccpovdef | Contains installation-specific information useful for reinstallation. |
$CCP_REL/mng/config | Contains installation-specific information useful for reinstallation. |
$CCP_REL/mng/version_info | Contains installation-specific information useful for reinstallation. |
$CCP_REL/data | Contains files related to contents of transactions. |
$CCP_REL/logs | Contains logs related to transactions. |
There are no client directories/files that need to be backed up.
This section describes the steps to be followed to completely restore a CPC installation. Restoration occurs in a number of phases:
Ensure that there is a working Informix server, as if the system were being installed for the first time. Depending on the reasons for the restore, this may require reinstallation. If the CPC database is still intact:
Step 2 Perform a Level-0 archive, as described above.
Step 3 Delete the database by executing
dbaccess -dd
and selecting the CPC database.
During this phase, the CPC server is reinstalled from the original media.
Step 2 If the previous installation exists, move it aside to a new name, for example, /opt/CPC/server.old.
Step 3 Install all components and upgrades in the order received from Cisco as if this were a new installation. Ensure that the installation is placed into the same directory as the old one. Only the database name, Informix server name and password need to be correct. The other configuration parameters will be restored at a later time.
Step 4 If the media containing the client installation was damaged, reinstall the client also.
This phase performs a cold restore of the Informix system.
Step 2 If the server is still running, shutdown it down by executing:
onmode -ky
Step 3 Find the latest Level-0, Level-1 and Level-2 archive tapes, along with the administrative backups.
Step 4 Restore the administrative files associated with the Level-0 archive. Ensure that all devices referenced in these files are available and operational.
Step 5 Execute
ontape -r
This will restore the database server. The operator is expected to respond to the prompts as required. The server will be left in quiescent state at the end of the operation. Bring it on-line by executing:
onmode -m
Restore the CPC server and client files from the latest backup tapes as follows:
| Directory/File | Contents |
|---|---|
$CCP_REL/mng/utility/syccpenvsetup | Restore. CCPPASSWORD may need to be modified if the Informix server password has been changed since the last backup. |
$CCP_REL/mng/utility/syccpovdef | Restore. |
$CCP_REL/mng/config | Restore. |
$CCP_REL/mng/version_info | Do not restore. |
$CCP_REL/data | Restore. |
$CCP_REL/logs | Restore. |
This phase is used to synchronize the restored state of CPC with the actual state of the network.
Step 2 Re-upload all fabric and connections from the network.
Online backups permit backup procedures to be done without shutting down CPC. While this improves CPC availability, a restore may result in the loss of some audit information. Online backup/restore is not supported at this time.
The following administration files are available for use with CPC:
Template files are located in the $CCP_REL/mng/template directory. They are copied and edited as part of the system configuration and placed in the specified directories. The following template files are available:
This file defines user-specific environment variables. It must be tailored for the specific user environment. In a Client installation, a copy of this file is automatically placed in each user's directory located in $CCP_REL/user.
This is a template file for the security system. It contains information about usernames and usertypes. During installation, a copy of this file is automatically placed in the $CCP_REL/data/security directory.
This is a template file containing site-specific configuration variables. During installation, a copy of this file is automatically placed in $CCP_REL/mng/config.
This is a template, site-specific configuration parameter file used the by syccnptsetup command. During installation, a copy of this file is automatically place in $CCP_REL/mng/config.
This is a prototype script used for automating CPC file system maintenance activities. Entering a crontab entry will allow you to run this script periodically to cleanup CPC log files. This script runs the synptclean utility.
This is a prototype profile file for the CPC Admin account. It includes basic environment variables that need to be set with the appropriate pathnames before CPC is installed.
This is a template file that provides additional Java tracing during Threader processing. It is a Java properties file that contains a description of how to enable/disable Java tracing. For the file to be active it must be placed in the Client's home directory, while any output generated is sent to a named file in $CCP_OUTPUT/current/syclient_<PID>.
This is a prototype shell script for automating CPC startup and shutdown. The script starts CPC in Server mode and ensures that CPC is cleanly shutdown when the system is brought down.
This is a prototype shell script for automating the startup and shutdown of CORBA daemons.
Utility files are located in the $CCP_REL/mng/utility directory. The following utility files are available for use by the System Administrator.
This file cleans up log and core files.
usage: synptclean [{-A | -a | -c | -s saveCount}] [-rz]
where, if -r | -z are not specified:
If -r | -z are specified:
Notes for -r option:
After the input parameters are validated, the utility attempts to build the list of files before actual delete operation. Building the list takes some time if there are a lot of transactions in the $CCP_REL/data/chreq directory.
Examples:
a. To delete all CR and UR transactions in the $CCP_REL/data/chreq directory:
<SERVER> synptclean -r
b. To delete only succeeded CR transactions:
<SERVER> synptclean -rz
Notes for -A, -a, -c options:
The -A option will attempt to delete the following directories:
$CCP_LOG/debug/* $CCP_LOG/site/* $CCP_LOG/siteerror/* $CCP_LOG/event/* $CCP_LOG/systemadmin/*
After the input parameters are validated, the utility checks to see if the system is running.
Examples
a. Try to use the different options while the system is running:
<SERVER> synptclean -A
System is running - can't delete all files <SERVER> synptclean -a
System is running - can't delete all files <SERVER> synptclean -a
rm -fr /opt/cpc/Server/log/output/1999-01-21.16:40:23
rm -fr /opt/cpc/Server/log/output/1999-01-21.16:21:15
rm -fr /opt/cpc/Server/log/output/1999-01-21.16:05:30
Note that the utility does not delete audit log files.
This file causes the network interface (NIF) for the specified equipment module to become simulated and thus provisioning will be simulated.
usage: synifstub [{-u | -s | -h equipment_module_name}]
where:
Examples:
a. To unstub the xyz equipment module, enter:
<SERVER> synifstub -u xyz
b. To stub the xyz equipment module, enter:
<SERVER> synifstub -s xyz
c. To display the message, enter:
<SERVER> synifstub -h
This utility allows you to get information and configure your Informix database. For more information about dbaccess and the Informix database refer to your Informix documentation. This utility allows you to:
You can access dbaccess through the interactive user interface or through scripting.
The behavior of CPC is controlled by a configuration management system that is driven by a combination of environment variables and configuration variables loaded from one or more configuration files.
CPC uses a number of environment variables to identify directories in the runtime structure. The variables are:
Configuration variables are stored in configuration files consisting of a series of parameter/value pairs.
The values for configuration parameters are contained in plain ASCII files called configuration files that can be manipulated with any standard UNIX commands or tools. The files are opened and read when a process starts, and when a process is reconfigured. They are not accessed at any other time.
Configuration files have a very simple syntax and contain only two types of lines, parameter definitions and comments.
In general, white space is ignored (except between quotes), and each command must appear on a separate line, terminated by a line feed.
To define a parameter, the value can be one of several types:
Comments
Any line that begins with a # character is a comment and is ignored. Comment can also follow the parameter/value pair.
File Hierarchy
The system supports configuration parameters being contained in several files, thus providing for a hierarchy of configuration files. CPC is delivered with a configuration file containing default values for all parameters needed to run the system, exclusive of certain system specific values such as the names of the trusted hosts, and the license authorization string.
The configuration variables are divided into a number of groups:
Operational Variables
This section describes the CPC-specific configuration parameters which control the normal behavior of CPC. Each parameter has a description which includes keywords at the beginning to help locate the correct parameter.
| Variable | Description | Default | Valid Settings |
|---|---|---|---|
SYSSN.syviewmanagerLimit | The maximum number of View Manager sessions that can be started. The sum of SYSSN.syscriptmanagerLimit and SYSSN.syviewmanagerLimit is controlled by the runtime licensing. | 10 |
|
SYSSN.syscriptmanagerLimit | The maximum number of Script Manager sessions that can be started. The sum of SYSSN.syscriptmanagerLimit and SYSSN.syviewmanagerLimit is controlled by the runtime licensing. | 2 |
|
SYSSN.syperformerLimit | The number of Java sessions that can be started. | 10 |
|
SYOBO.logger | This parameter specifies the location of the NPT Logger. This parameter must be specified, as there is no default. This value is specified in the form node:port. For example, if the logger is running on the node gazelle using port 7218, the value for this parameter would be gazelle:7218. |
| any valid text string |
SYOBO.nameserver | This parameter specifies the location of the NPT Name Server. This parameter must be specified, as there is no default. This value is specified in the form node:port. For example, if the logger is running on the node gazelle using port 7218, the value for this parameter would be gazelle:7218. |
| any valid text string |
SYOBO.trustedHosts | This parameter specifies other hosts that are allowed to establish connections to NPT processes. If this parameter is not specified, then connections will only be accepted from the same node. The value is a space separated list of nodes. For example, if the back-end processes are running on the node gazelle, and the front-end processes are running on nodes vesta and zeus, then the value for the parameter would be gazelle vesta zeus on the server and gazelle on the client machines. The machines should have entries for the names in the /etc/hosts file. |
| any valid text string |
SYOBO.watchdog | This parameter specifies the location of the NPT WatchDog Server. This parameter must be specified, as there is no default. The value is specified in the form node:port. For example, if the Watchdog is running on the node gazelle using port 7220, the value for this parameter would be gazelle:7220. |
| any valid text string |
This section described the CPC-specific configuration parameters which control the debug behavior of CPC. Debugging variables are available for all of the Equipment Modules, the Engine, and Frame Relay Services.
For a list of all of the debugging variables, refer to the specific files in the $CCP_REL/mng/config directory.
When you start the CPC Server, it results in the startup of the following background processes:
Figure 19-1 describes the processes that make up CPC.
There are five types of processes in CPC, and processes of the same type follow the same behavior patterns.
| Icon | Description |
|---|---|
| A Transaction Server provides access to the CPC database. This type of server has been optimised for fast startup - a single copy is created on NP startup which then forks itself as needed. |
| An Iterative Server processes requests sequentially. This type of server deals with low-volume short-duration requests which are processed one at a time. |
| A Dispactcher and Executor together make up a Concurrent Server. This type of server deals with long-duration activities where parallelism is required. The Dispatcher receives requests and forks/execs and Executor to deal with each new long-duration activity. |
| An Ad-hoc Client process is one which is started as needed to perform some activity, and terminates when the activity is complete. It may use the services of other processes. |
A Session is the basic unit of concurrency within CPC. There is a separate foreground session for each logged-in user and a background session for processing Transactions (i.e. handling the Preparation, Delivery and Activation stages of the Transaction lifecycle). Background sessions can also be started to import or export data. Scripts which run on behalf of a logged-in user normally share the user's foreground session, but background scripts can also be written which run in their own session.
A number of processes are involved in each session. Some processes are dedicated to the session whereas others are shared by all sessions. All sessions access the CPC database and hence all sessions will have a CCS Server process. Also, every session has at least one process that is playing the role of client for the session. In some sessions the session client processes are running on the CPC Client system whereas in others all of the processes (client and server) are running on the CPC Server system.
A foreground session has a View Manager, Viewers and a CCS Server. It can also have Script Interpreter, Map Interface and Help Interface processes as needed. All processes are session clients except the CCS Server.
A Transaction Processing session has a Change Initiator (the session client), a CCS Server and a number of Site Executors.
A script session has a Script Interpreter (the session client) and a CCS Server.
An import or export session has the import/export process (the session client) and a CCS Server.
All of the other processes (CR Controller, Change Initiation Manager, Site Dispatcher, Logger, Security Server, Name Server, MVC Server, Process Manager and Watchdog) are shared by all sessions.
| Icon | Description |
|---|---|
| The CCS Server is the heart of CPC. This process contains all of the CCS and CMS objects and all of the associated Infrastructure (Check Engine, Translate Engine, Managed, Persistence, etc.) All database access is via this type of process--persistent objects are retrieved from the database into an object cache within the process memory where they can execute. A session's Transaction and Network Elements are in this process |
| The CR Controller manages the state of all Transactions. It ensures that a transaction is not openned by two sessions simultaneously--CCS Server processes ask the CR Controller for permission to open a Transaction. It controls the Processing phase of a Transaction--Transactions ask the CR Controller for permission to Deliver and Activate changes. |
| The Change Initiation Manager controls background session activity. It manages a queue of the Transactions which are scheduled for processing, and starts a Change Initiator for each Transaction when it begins processing. The Change Initiation Manager can also be used to synchronized import and export sessions. |
| The Change Initiator drives a Transaction through the Processing parts of the lifecycle. It starts a session and invokes a CCS Server, which prepares and commits the changes and then invokes a Site Dispatcher to deliver and activate them. |
| The View Manager controls a GUI session. It is the process which is started when a user starts the CPC GUI, and it manages all of the Viewer processes in the user's session. A Viewer process can request the View Manager to start another Viewer process (e.g. when a user double-clicks on a row in a list window the Viewer which is displaying the list requests the View Manager to start a new Viewer to display the selected objects.) |
| The Viewer displays one configuration or list window (and associated sub-windows). There are three viewers executables supplied with NPT:
|
| The Script Interpreter is started by a Korn shell (ksh) when the shell script containts CPC Script Language commands. The Script Interpreter communicates with its associated Korn shell via pipes (using the co-process feature of ksh.) |
| The Site Dispatcher controls the Network Interface. It manages the individual Site Executor processes--it starts a Site Executor in response to a deliver, activate or rollback request from a Transaction, for each site involved in the CR. |
| The Site Executor delivers and activates changes to a specific site in the managed network. It contains a Site Delivery and Site Activation package. |
| The Name Server, MVC Server, Process Manager, Security Server, Watchdog, and Logger processes contain the corresponding CPC components. |
| The MVC Server (Model View Controller) process manages events. |
| The Security Server process provides an interface for ojbects that access the security information file. |
| The Watchdog process brings down all associated components when one of the critical processes fail. |
| The Logger process manages messages into the log files. |
| The DBMS used by the application will also have its own processes. Each DBMS has a different process architecture. |
The CPC crash recovery utility (SYavcru) is a program designed to run at system startup on the Server side. Its purpose is to assist in automated recovery after a system crash. This utility is designed to do its work on Transactions that were non-terminal before the system crash, and bring these Transactions to a terminal state.
When started, the utility will obtain a list of all Transactions in the system that are in non-terminal states. It then handles these Transactions according to the rules defined below. The exact action depends on the state of the Transaction, as well as one or more time-related attributes.
1. SYavcru will reject and monitor any Transaction that:
a. has an opendate attribute representing a time before the system started, and
b. is in one of the following states: Ready or Alert.
2. SYavcru will monitor any Transaction that:
a. has a scheduledate attribute representing a time before the system started, and
b. is in one of the following states: Busy.
3. SYavcru will stop monitoring any monitored Transaction that enters one of the following states:
a. Applied
b. Abandoned
4. SYavcru will reject any monitored Transaction that enters one of the following states:
a. Alert
b. Ready
CPC maintains log files for the Server and Client.
The following directories which hold system log files can be found in the CPC Server or Client $CCP_REL/log directory:
Before starting CPC, all environment variables should be initialized by the syccpovdef utility.
The Server and Client are installed in different directories.
For example, $CCP_REL of the Server is /opt/cpc/Server and the $CCP_REL of the Client is /opt/cpc/Client.
Some of the Client log files are set up as links to the Server log directories. In the following example the audit, event, site error, and system admin logs are linked to the Server log directory.
<Client> cd /opt/cpc/Client/log <Client> ls -ls total 14 2 lrwxrwxrwx 1 joe staff 28 Oct 21 15:31 audit -> opt/cpc/Server/log/audit 2 drwxrwxr-x 2 joe staff 512 Oct 20 13:40 debug 2 lrwxrwxrwx 1 joe staff 28 Oct 21 15:31 event -> /opt/cpc/Server/log/event 2 drwxrwxr-x 20 joe staff 1024 Nov 16 15:35 output 2 drwxrwxr-x 2 joe staff 512 Oct 20 13:40 site 2 lrwxrwxrwx 1 joe staff 32 Oct 21 15:31 siteerror -> /opt/cpc/Server/log/siteerror 2 drwxrwxr-x 2 joe staff 512 Oct 20 13:40 systemadmin -> /opt/cpc/Server/log/systemadmin
The audit log and site log of a transaction can be read from the Transaction Manager GUI or from standard UNIX utilities. The output, system administration, event, site error, and debug logs can be read from standard UNIX utilities.
When a transaction is deleted, the corresponding logs are deleted. A CR delete entry in the system administration log is the only trace left by a deleted transaction.
An audit log records the lifecycle of a specific transaction. For example, in a successful transaction, the Created, Approved, Scheduled, Processing, Committing, and Succeeded states of the CR are logged.
The audit log also contains information about what Service Object has been created or deleted.
Audit logs are stored in the Server $CCP_REL/log/audit directory
For example, to list the audit logs:
> cd $CCP_REL/log/audit > ls *110* audit1100 audit1101
where 1100 and 1101 are the transaction numbers. The audit log will be deleted when the transaction is manually deleted from the Transaction Manager.
The following is an example of the content of the audit log for transaction 1100:
11/09/98 16:14:12 SYCCSSSS006003I1 1016 CR Created by joe 11/09/98 16:14:12 SYCCSSSS006004I1 1016 CR Submitted for Approval by joe 11/09/98 16:14:13 SYCCSSSS006029I1 1016 CR Approved by joe from Approval Request 11/09/98 16:14:13 SYCCSSSS006006I1 1016 CR Opened by joe from Approved state 11/09/98 16:25:49 SYCCSSSS006011I1 1016 RF ServiceObject: Created by joe 11/09/98 16:25:54 SYCCSSSS006007I1 1016 CR Closed by joe from Opened state 11/09/98 16:25:54 SYCCSSSS006024I1 1016 CR Reject action requested by joe 11/09/98 16:26:01 SYCCSSSS006017I1 1016 CR Rejected from Rejecting state
A site log records various delivery and activation states.
Site logs are stored in $CCP_REL/log/site
Each site log is identified by the transaction number and the site. For example, to list the site logs for transaction 2556:
> cd $CCP_REL/log/site > ls *2556* site2556_CsNetl site2556_CsNet2
The following is an example of the content of the site log:
10/27/98 13:26:21 SYCCSCDF010022I1 1100 Site CsNet1 entered Preparation In-Progress from Preparation Scheduled 10/27/98 13:26:27 SYCCSCDF010022I1 1100 Site CsNet1 entered Delivery Scheduled from Preparation In-Progress 10/27/98 13:26:32 SYCCSCDF010022I1 1100 Site CsNet1 entered Delivery In-Progress from Delivery Scheduled 10/27/98 13:26:32 SYCCSCDF010022I1 1100 Site CsNet1 entered Activation Scheduled from Delivery In-Progress 10/27/98 13:26:34 SYCCSCDF010022I1 1100 Site CsNet1 entered Activation In-Progress from Activation Scheduled 10/27/98 13:26:36 SYCCSCDF010022I1 1100 Site CsNet1 entered Succeeded from Activation In-Progress
The output log keeps miscellaneous types of log files or debug files created while running CPC.
 |
Note The output log files should be removed on a regular basis. Refer to the activator.cron template file for more information. |
Output logs are stored in $CCP_REL/log/output
Each output log is identified by the date and time. The current log is linked to the log file with the current date and time. For example, to list the output logs for November 17, 1998, enter:
> cd $CCP_REL/log/output > ls -l drwxr-xr-x 20 joe staff 1024 Nov 17 10:19 1998-11-17.10:12:04 drwxr-xr-x 17 joe staff 512 Nov 17 11:18 1998-11-17.11:17:39 drwxr-xr-x 17 joe staff 512 Nov 17 11:20 1998-11-17:11:19:19
The following is an example of the content of the output log:
drwxr-xr-x 17 joe staff 512 Nov 9 11:19 SYCCSServer_1756 drwxr-xr-x 17 joe staff 512 Nov 9 11:19 SYCCSServer_1774.0 drwxr-xr-x 17 joe staff 512 Nov 9 11:19 SYCCSServer_1778.0 drwxr-xr-x 17 joe staff 512 Nov 9 11:19 SYCCSServer_1787.0 drwxr-xr-x 17 joe staff 512 Nov 9 11:19 SYCRController_1773 drwxr-xr-x 17 joe staff 512 Nov 9 11:19 SYChangeInitiationManager_ drwxr-xr-x 17 joe staff 512 Nov 9 11:19 SYLogger_1752 drwxr-xr-x 17 joe staff 512 Nov 9 11:19 SYMVCServer_1754 drwxr-xr-x 17 joe staff 512 Nov 9 11:19 SYNameServer_1751 drwxr-xr-x 17 joe staff 512 Nov 9 11:19 SYSecurityServer_1753 drwxr-xr-x 17 joe staff 512 Nov 9 11:19 SYSiteServer_1755 drwxr-xr-x 17 joe staff 512 Nov 9 11:19 SYWatchDog_1750 drwxr-xr-x 17 joe staff 512 Nov 9 11:19 SYnpt_1749 drwxr-xr-x 17 joe staff 512 Nov 9 11:19 Syavcru_1779 drwxr-xr-x 17 joe staff 512 Nov 9 11:19 Syclient_1788
Each directory in this example is associated with a process that CPC is running. Each of these directories contains a stdout file, which is a text file that contains the error message information.
The system administration log files record conditions that require system administrator action, for example, disk full, memory low, or upload failure.
The system administration log can be found in $CCP_REL/log/systemadmin.
Manually deleted CRs will leave a trace record in the system administration log.
The following is a example of the content of the system administration log:
10/21/98 16:22:38 SYINFUPL105120F1 Upload Failed. [Upload Request: 1004] 10/21/98 16:22:38 SYINFUPL105195F0 Internal error. Failed. [Upload Request: 1004] 11/02/98 12:34:25 SYCCSCAD006041I1 CR 1070 Deleted by joe from Rejected state 11/02/98 12:34:34 SYCCSCAD006041I1 CR 1071 Deleted by joe from Rejected state 11/02/98 12:34:44 SYCCSCAD006041I1 CR 1072 Deleted by joe from Succeeded state 11/02/98 12:34:56 SYCCSCAD006041I1 CR 1073 Deleted by joe from Succeeded state
The event log files contain information about system level events and errors.
The event log is stored in $CCP_REL/log/event
The following is an example of the content of the event log:
11/09/98 15:57:44 SYINFSCC037005I1 05011 05011 Task startup ok 11/09/98 15:58:20 SYINFSCC037007I1 05011 05011 Task shutdown 11/09/98 15:58:22 SYINFSCC037005I1 05035 05035 Task startup ok 11/09/98 15:59:32 SYINFSCC037007I1 05035 05035 Task shutdown 11/09/98 15:59:33 SYINFSCC037005I1 05064 05064 Task startup ok 11/09/98 16:00:44 SYINFSCC037007I1 05064 05064 Task shutdown 11/17/98 11:11:35 SYCCSATR085300F0 01647 Internal error. 11/17/98 11:11:35 SYCCSCAD006048E1 01647 Database instantiation failed 11/17/98 11:11:35 SYCCSMED087005F1 01647 Failed to construct metadata. 11/17/98 11:11:35 SYCCSMED087325F0 01647 Metadata Internal Error. 11/17/98 11:11:35 SYCCSMED087005E1 01647 Failed to construct metadata. 11/17/98 11:11:35 SYCCSMED087000E1 01647 Function setup: failed processing. 11/17/98 11:11:35 SYCCSPRS017062F1 01647 Database problem for (joe) 11/17/98 11:11:35 SYCCSPRS017300F0 01647 Problem with database transaction. 11/17/98 11:11:35 SYCCSPRS017001F1 01647 Start database transaction error 11/17/98 11:11:35 SYCCSPRS017300F0 01647 Problem with database transaction.
The site error log files contain information about all of the errors that a site encounters during processing.
The site error logs are stored in $CCP_REL/log/siteerror.
The debug log files contain information from all of the executables that had the debugging variables turned on.
Debug logs are found in $CCP_REL/log/debug
The following is an example of the content of the debug log:
10/07/98 15:28:16 SYCCSSCM073003I1 11286 attrName : domain attrData : 10/07/98 15:28:16 SYCCSSCM073003I1 11286 attrName : vpn attrData : 10/07/98 15:28:16 SYCCSSCM073003I1 11286 attrName : domain attrData : 10/07/98 15:28:16 SYCCSSCM073003I1 11286 attrName : vpn attrData : 10/07/98 15:28:16 SYCCSSCM073003I1 11286 NumOfNewCCFObjects : 0 10/07/98 15:28:16 SYCCSSCM073003I1 11286 NumOfNewCCFObjects : 0 10/07/98 15:28:16 SYCCSSCM073003I1 11286 NumOfNewCCFObjects : 0 10/07/98 15:28:16 SYCCSSCM073003I1 11286 NumOfNewCCFObjects : 0
Posted: Thu Aug 3 16:45:35 PDT 2000
Copyright 1989-2000©Cisco Systems Inc.
