This chapter provides suggestions on how to resolve Sun JavaTM Enterprise System (Java ES) installation and uninstallation problems.
This chapter includes the following sections:
This section provides guidelines for analyzing and identifying the source of problems during installation and uninstallation of Java ES.
This section contains the following subsections:
If a problem occurs during installation or uninstallation, the first place to look for information on what happened is the installation logs. Informational, warning, and error messages are issued after such operations as user choices, package manipulations, and installation or uninstallation steps. Messages on installation, uninstallation, and install-time configuration are gathered into the source log files. Information that is displayed for each message includes date and time, log level, module ID, and the message text. Passwords are never included.
There are four types of log files that capture installation or uninstallation information:
A summary provides a high-level description of what was installed and configured.
A detail version A file contains completion information.
A detail version B file contains more details on the log messages.
A debug file contains information that is relevant when installation fails. Use the debug file when one of the other log files indicates an error.
The log messages are stored in a Sun standard format called Unified Logging Format (ULF). If you find ULF difficult to read, you can use the Java ES Log Viewer to view the log messages.
Source log files can be edited with a text editor. The following table lists the formats of the source log files.
Table 9–1 Log File Formats
Logged Entity |
Log File Name Format |
---|---|
Installer |
Java_Enterprise_System_5_install.Atimestamp |
Java_Enterprise_System_5_install.Btimestamp |
|
JavaES_Install_log.timestamp |
|
Java_Enterprise_System_5_Summary_Report_install.timestamp |
|
Uninstaller |
Java_Enterprise_System_5_uninstall.Atimestamp |
Java_Enterprise_System_5_uninstall.Btimestamp |
|
JavaES_UnInstall_log.timestamp |
|
Java_Enterprise_System_5_Summary_Report_uninstall.timestamp |
After an uninstallation, the uninstaller removes the installer, the Log Viewer , and itself. However, source log files are not removed and are stored in the following locations:
Solaris: /var/sadm/install/logs
Linux: /var/opt/sun/install/logs
Examine the summary file. For example:
Java_Enterprise_System5_Summary_Report_install.timestamp
If a problem occurred, determine which component caused the problem. Determine if multiple problems occurred. You will probably need to look at one or both of the detail logs.
Examine the detail log. For example:
JavaES_Install_logtimestamp
Look for the first error or warning that occurred and resolve it. Sometimes resolving one error resolves a number of seemingly unrelated errors that follow.
The Java ES Log Viewer provides a graphical display for viewing the ULF log messages from the JavaES_Install_log.timestamp file or the JavaES_UnInstall_log.timestamp file. You display a log file by selecting Open in the File menu on the Log Viewer main page. If the file you specify already exists or cannot be opened for writing, a Log Viewer error occurs and you are returned to the Log Viewer main page. Such a file cannot exist in the directory used by the installer to store source logs.
The messages that meet your filtering criteria are displayed in a single log table when you click the Search button. After the log table is displayed, an individual row in the log table can then be selected for detailed display, including display in multiple-line format.
To tailor your logging output, you indicate your display preferences and search criteria on the Log Viewer main page after you have selected a ULF log file. Display Preferences indicate what language you want your selection displayed in, and what limitations to apply in displaying the filtered records.
Language. Chooses a translation language for viewing messages. The default is English. This list is populated from the translation resource bundles stored by the installer. If a resource bundle is not specified, messages and the Log Viewer interface are displayed in English.
Timestamp. Sets the records to be filtered or displayed. Choices are View All, Most Recent, and Oldest.
View All. All data is filtered and displayed.
Most Recent. All data is filtered, and the most recent data is displayed first.
Oldest. All data is filtered, and the oldest data is displayed first.
There are three ways to filter messages so that the messages displayed are of sufficient importance or interest: by log level, by logger, and by content.
Log Level. Chooses a log level for filtering messages. Choices are SEVERE, ERROR, WARNING, INFO, CONFIG, FINE, FINER, and FINEST. Selecting FINEST is equivalent to selecting all records for display. When you select a log level, only messages having that log level or a level greater in severity are displayed. If you do not want to include any message except those that have the exact log level you specify, click the Do not include more severe messages checkbox.
Logger. Chooses none or one of the loggers that apply to the file you opened. A logger (moduleID in a ULF file) indicates what part of the installer is writing the log message. The main loggers are JAVAESConfig, JAVAESInstall, or JAVAESUninstall. Only messages associated with the logger you selected are displayed. In addition, product component loggers can be specified. For example, WebServerInstall, AccessManagerConfig, DirectoryServerUnInstall.
Content. When you enter a string, such as “configure,” in the Only Show Entries Containing text box, only messages that contain that string are selected.
Some typical search criteria:
Display only the SEVERE log messages in this file.
Display only the log messages with a log level greater than or equal to ERROR.
Display only the log messages from installation that have a log level greater than or equal to ERROR.
Display only the log messages from uninstallation events.
Because the Log Viewer operates in read-only mode, multiple users can run the Log Viewer at the same time.
On the command line, navigate to the location of the Log Viewer:
Solaris SPARC: /var/sadm/prod/SUNWentsys5u1i/Solaris_sparc
Solaris x86: /var/sadm/prod/SUNWentsys5u1i/Solaris_x86
Linux: /var/sadm/prod/sun-entsys5u1i/Linux:_x86
Start the Log Viewer.
./viewlog |
The Log Viewer main page is displayed.
In the File menu, select a log file for display.
If the file you select is not ULF, you receive a message saying the selected file is not ULF and cannot be selected. Only ULF files can be displayed using the Log Viewer.
If no ULF log files are available, the installation or uninstallation might not be completed yet. Wait and try again.
Choose Display Preferences and Search Criteria for your scenario.
Click Search.
The log table displays the records that match your filtering criteria.
A number of product components have installation-time interdependencies. Problems that affect one product component can affect other product components. First, you should familiarize yourself with the information in Sun Java Enterprise System 5 Installation Planning Guide.
Review the summary file and log files to see whether related products have failed. These might provide a clue as to what to fix first.
Check that you have specified correct connection information. For example:
Does the information that you provided when configuring Directory Server match the directory information you provided for product components that use that Directory Server?
Does the Access Manager information that you provided for Portal Server or Portal Server Secure Remote Access match the information you provided for Access Manager?
In addition to product component interdependencies, some product components depend on the existence of Solaris packages that might not be installed on the host. The absence of these packages could cause installation failures. Read the “Software Requirements” section of the Release Notes for details.
If a problem occurs starting a product component, examine that product component's log files. Locations of many product component log files are listed in Product Component Troubleshooting Tips.
The following host-level issues can cause installation problems.
Updates. Have you applied the recommended updates (patches)?
Disk Space. How is the disk partitioned, and to what partitions do installation directories point? The installation directories /var/sadm and /etc/opt, or the non-default directories that you specify, need sufficient disk space.
Network Ports. During configuration, you supply port numbers for Java ES product components. Check the following:
Examine the standard port numbers in the file /etc/services .
Look at the summary log file to compare your settings with the standards. Did you mistype a port number or set one server to the port that is typically used for another?
Use the command netstat -a to view current port use on the system. Did you assign a port number that was already in use?
IP Addresses. During configuration, you specify IP addresses. Check that you entered the correct IP addresses. These are some questions to resolve:
Does this system have multiple network interfaces, each with its own IP address?
In a high availability configuration, did you specify the IP address of the logical host or the IP address of a cluster node?
If you are having problems starting product components, verify that the procedures outlined in Chapter 6, Completing Postinstallation Configuration were followed correctly.
If you are installing a product component that relies on Directory Server, problems can be caused by one of these problems:
You specified an incorrect user ID and password for Directory Server.
You specified an incorrect LDAP port.
Directory Server is unreachable.
The interactive modes of the installer check for Directory Server connectivity during installation, but silent mode does not. If you perform a silent installation when Directory Server is not available, installation of Access Manager or Portal Server could fail.
To prevent the overwriting of customized files, such as edited configuration files, Web Server cannot be installed into a directory that contains files.
If you are reinstalling Web Server, check the installation directories to ensure that they are empty. If they are not empty, archive the files elsewhere and retry the installation.
The installer queries you to supply a number of passwords for product components. If you are installing different product components on different hosts, it is important to ensure that you supply matching passwords on each host.
To resolve password problems, you might need to uninstall and then reinstall. If the uninstall fails, refer to Installation Fails Due to Files Left Behind During an Uninstallation.
If you have installed product components but are having problems and cannot reinstall or uninstall, check the installed component packages using the Solaris pkginfo command, the Linux rpm command. Compare the results with the Java ES packages listed in Chapter 5, List of Installable Packages, in Sun Java Enterprise System 5 Update 1 Installation Reference for UNIX. Additional troubleshooting information is in Installation Fails Due to Files Left Behind During an Uninstallation.
On Solaris 9 and Solaris 10, you can also use the product registry (prodreg tool) which provides a graphical interfaces that indexes components and their packages, superseding the pkg utilities. To invoke the product registry, type prodreg at the command prompt. For more information, refer to the prodreg(1) man page.
During uninstallation, you might need to grant administrator access to the uninstaller, as described in Granting Administrator Access for the Uninstaller.
This section addresses the following problems you might encounter during installation.
Installation Fails Due to Files Left Behind During an Uninstallation
Installation Fails Due to Removed Shared Components in Product Registry After Uninstallation
Cannot Configure IBM WebSphere as the Portal Server Web Container
Silent Installation Fails: “State File is Incompatible or Corrupted”
Uninstallation can leave behind product component files or packages. In such a case, you might need to manually remove the files or packages before you can reinstall Java ES. The installer reports that the product component is on the host, even though you thought you removed it.
The following might have occurred:
The uninstallation failed and an error message provided the name of the package that was not uninstalled, but no one resolved the problem.
The uninstallation failed but the error was not detected, so you believe packages were uninstalled when they were not.
Use the following command to determine whether any packages were partially installed.
Solaris OS: pkginfo -p
Linux: rpm -qa |grep —I ^sun | xargs rpm -V
The command output lists any partially installed packages. Using the package names returned, refer to Chapter 5, List of Installable Packages, in Sun Java Enterprise System 5 Update 1 Installation Reference for UNIX to discover what product component the packages belong to.
Remove components or packages.
On Solaris 9 or 10, use the prodreg tool.
The prodreg tool manages the package-based components on your host. You can view product components and their packages, with full information, including interdependencies. You can use the prodreg tool to safely uninstall product components and remove packages. Once you have removed a product component with the prodreg tool, you can reinstall.
On Linux, use the rpm -e command.
To edit the product registry file, open the file /var/opt/sun/install/productregistry. This XML file describes each product component. Each product component description starts with a <compid\> tag and ends with a </compid\> tag. Delete the entire entry for the product component.
Verify that the following directories do not contain Java ES product components or packages:
/opt
/etc/opt
/var/opt
Run the installer again.
As of the Java ES 5U1 release, shared components are listed in the product registry file after installation.
The Java ES uninstaller removes product components from the system but does not remove shared components. After an uninstallation, the product registry still contains entries for the shared components. If you manually remove any Java ES shared components after an uninstallation, these components are not removed from the product registry. Thus, the next Java ES 5U1 installation fails because the installer assumes that the manually deleted shared components are present (because they still have entries in the product registry file).
Avoid manually removing Java ES shared components from your system.
Suggested Fix. Either remove the corresponding entries from the product registry file or remove the product registry file itself. Removing entries from the product registry file can cause the file to become corrupted, so you might prefer to remove the whole product registry. Before doing this, verify that products other than Java ES components are not using the product registry file.
On Linux there is no equivalent of the graphical product registry that exists on Solaris OS. If you manually removed files on Linux , you must manually edit the product registry file to remove those entries.
WebSphere might not be running, or you might have specified a WebSphere value that does not match the WebSphere native configuration. There are two approaches to troubleshooting this issue. IBM WebSphere is only supported as a web container on Solaris OS.
One approach is to check the configuration of your WebSphere instance.
Ensure that WebSphere is running.
Examine the values for the following installer fields:
WebSphere Virtual Host (PS_IBM_VIRTUAL_HOST in the state file)
Application Server Name (PS_IBM_APPSERV_NAME in the state file)
Use the WebSphere tools to check the configuration to make sure it matches the values you are entering.
Try again.
Another approach is to create new instances of the WebSphere entities.
Use the adminclient.sh to start the WebSphere console.
Create a new virtual host instance and a new Application Server instance name.
Click the entry under Nodes (typically the host name), and select Regen WebServer Plugin.
This process saves the new entries into the plugin configuration file, which the installer checks for the legal names.
Return to the installer and enter the values you just created.
A power failure or system failure might have occurred, or you might have entered CTRL/C to stop the installer process.
Suggested Fix. If the failure occurred during the installation or configuration process, you are probably left with a partial installation. Run the uninstaller. If the uninstaller fails, follow the instructions under Uninstallation Fails, Leaving Behind Files
The installer sometimes creates an image on the screen before the image is ready for input. You cannot repeatedly click Next in the installation wizard without waiting.
Suggested Fix. The button that represents the default choice includes a blue rectangle. This rectangle sometimes appears after the button itself appears. Wait until you see the blue rectangle before clicking a button.
If you are using a state file that was created on the same platform on which you are using it, the problem might be due to an unknown file corruption error. There are two approaches to troubleshooting this issue.
If you created the state file on the same platform on which you are running the silent installation, generate a new state file and reinstall.
If you are using a state file that was created on a different platform or version, the problem is that state files must be run on the same type of platform on which they are created. For example, if you created the state file on Solaris 9, you cannot use it on Solaris 10, or, if you created the state file on the x86 platform, you cannot use it on the SPARC platform.
If the platform on which you created the state file is not the same as the platform on which you are running the silent installation, create a new, platform-appropriate ID for the file. For instructions on how to do this, refer to Creating a Platform-Appropriate State File ID.
If you edited the state file, you might have introduced errors. Check the following and regenerate the state file as described in Creating a State File.
Are all local host parameters set, and are they set to consistent values?
Are parameter values in the correct case?
Did you delete a required parameter without entering a replacement?
Are all port numbers valid and unassigned?
Suggested Fix. Resolve the problem and regenerate the state file.
The most likely reason for this is that your MANPATH environment variable is not set correctly for the components you installed.
Suggested Fix. Update /etc/MANPATH to point to the new man page directory. Refer to Verifying Man Pages .
This section addresses the following problems you might encounter during uninstallation.
The Java ES installation program places the uninstaller on your system at the following location:
Solaris OS: /var/sadm/prod/SUNWentsys5u1
Linux: /var/sadm/prod/sun-entsys5u1
If the uninstaller is not in this directory, one of the following might have occurred:
Java ES was never installed on this host.
The Java ES uninstaller previously removed all product components and itself from this host.
During uninstallation, if the uninstaller detects that there are no Java ES product components on a host, it uninstalls itself.
During a failed installation, one of the following occurred:
The uninstaller was never installed on the host.
The uninstaller was removed, but some Java ES product components remain on the host.
Suggested Fix. Manually clean up your system as described in Uninstallation Fails, Leaving Behind Files.
If manual cleanup is necessary because the uninstaller left behind files or processes, perform the following procedure to remove packages from your system.
Determine which packages you want to remove.
Compare the packages on your system with the Java ES packages listed in Chapter 5, List of Installable Packages, in Sun Java Enterprise System 5 Update 1 Installation Reference for UNIX. (See also Installation Fails Due to Files Left Behind During an Uninstallation. You can use the following commands to determine which packages are installed:
Solaris OS: pkginfo or prodreg utility
Linux: rpm command
Stop all running processes for Java ES product components.
Brief instructions for stopping processes are contained in Chapter 6, Completing Postinstallation Configuration product component documentation.
Back up all custom configuration and user data you plan to use in subsequent installations.
Reviewing Uninstallation Behavior for Java ES Product Components provides some information on configuration and user data that should be backed up. For more information, refer to the product component documentation for each product component.
Use the pkgrm, rpm -e, or swremove command to remove Java ES component packages.
Remove any remaining product component directories and their content that you do not plan to use in subsequent installations. If you do plan to use these directories later, move them elsewhere.
Update the product registry file, which is located here:
Solaris OS: /var/sadm/install/productregistry
Linux: /var/opt/sun/install/productregistry
The uninstaller uses this registry to determine which product components are installed on a host. Both the installer and uninstaller update the product registry upon completion of an installation or uninstallation.
If you manually remove packages rather than using the uninstaller, then you must edit the product registry so it correctly reflects the software installed on your system.
Clean up the log files for your system, which are located here:
Solaris OS: /var/sadm/install/logs
Linux: /var/opt/sun/install/logs
The log files might not correctly reflect the state of your system after you manually remove packages.
During uninstallation, the uninstaller uses the product registry file to determine what needs to be uninstalled:
Solaris OS: /var/sadm/install/productregistry
Linux: /var/opt/sun/install/productregistry
If the uninstaller fails, you might need to retry after you restore the product registry from your backup copy.
If you manually remove packages, the product registry is not automatically updated. When you subsequently run the uninstaller, you might encounter problems because the product registry does not correctly reflect your system. In this case, you can try to reinstall and then run the uninstaller again.
This section addresses the following problems that might arise in relation to the common agent container shared component:
The common agent container (V2.1) included with Java ES reserves the following port numbers by default:
JMX port (TCP) = 11162
SNMP Adaptor port (UDP) = 11161
SNMP Adaptor port for traps (UDP) = 11162
Commandstream Adaptor port (TCP) = 11163
RMI connector port (TCP) = 11164
If you are troubleshooting an installation of Sun Cluster software, the port assignments are different because Sun Cluster software uses a different version of common agent container. In this case, default ports are as follows:
JMX port (TCP) = 10162
SNMP Adaptor port (UDP) = 10161
SNMP Adaptor port for traps (UDP) = 10162
Commandstream Adaptor port (TCP) = 10163
RMI connector port (TCP) = 10164
If your installation already reserves any of these port numbers, change the port numbers used by the common agent container as described in the following procedure.
For further information on the common agent container cacaoadm command, see the cacaoadm man page. If you cannot see this man page at the command line, verify that your MANPATH is set correctly. Refer to Verifying Man Pages .
The path to cacaoadm on Solaris is:
Common Agent Container V1.1 /opt/SUNWcacao/bin/cacaoadm
Common Agent Container V2.x /usr/sbin/cacaoadm
As root, stop the common agent container management daemon:
/usr/sbin/cacaoadm stop |
Change the port number using the following syntax:
/usr/sbin/cacaoadm set-param param=value
For example, to change the port occupied by the SNMP Adaptor from the default 11161 to 11165:
For Sun Cluster software, use previously-specified ports.
/usr/sbin/cacaoadm set-param snmp-adaptor-port=11165 |
Restart the common agent container management daemon:
/usr/sbin/cacaoadm start |
As root, stop the common agent container management daemon:
/opt/sun/cacao/bin/cacaoadm stop |
Change the port number using the following syntax:
/opt/sun/cacao/bin/cacaoadm set-param param=value
For example, to change the port occupied by the SNMP Adaptor from 11161 to 11165:
/opt/sun/cacao/bin/cacaoadm set-param snmp-adaptor-port=11165 |
Restart the common agent container management daemon:
/opt/sun/cacao/bin/cacaoadm start |
It might be necessary to regenerate security keys on a host running Java ES. For example, if there is a risk that a root password has been exposed or compromised, you should regenerate security keys. The keys used by the common agent container services are stored in the following locations:
The path to security on solaris is:
Common Agent Container V1.1:
Solaris OS: /etc/opt/SUNWcacao/security
Linux: /etc/opt/sun/cacao/security
Common Agent Container V2.x (default instance):
Solaris OS: /etc/cacao/instances/default/security
Common Agent Container V2.x, custom instance named <name>:
Solaris OS: /etc/cacao/instances/<name>/security
Under normal operation, these keys can be left in their default configuration. If you need to regenerate the keys due to a possible key compromise, you can regenerate the security keys using the following procedure.
As root, stop the common agent container management daemon.
/usr/sbin/cacaoadm stop |
Regenerate the security keys.
/usr/sbin/cacaoadm create-keys --force |
Restart the common agent container management daemon.
/usr/sbin/cacaoadm start |
In the case of Sun Cluster software, you must propagate this change across all nodes in the cluster. For more information, see How to Finish a Rolling Upgrade to Sun Cluster 3.1 8/05 Software in Sun Cluster Software Installation Guide for Solaris OS.
As root, stop the common agent container management daemon.
/opt/sun/cacao/bin/cacaoadm stop |
Regenerate the security keys.
/opt/sun/cacao/bin/cacaoadm create-keys --force |
Restart the common agent container management daemon.
/opt/sun/cacao/bin/cacaoadm start |
For more information on the cacaoadm(1M) command, see the cacaoadm man page.
This section addresses various problems that might arise after installation.
If you have restarted Application Server, the communication between Application Server and Monitoring Console has been disrupted and needs to be reactivated. Monitoring rules that were previously working, no longer work and are in a status of Unknown. If you have restarted the common agent container on the Application Server host, the problem will still exist because the common agent container must also be restarted on the Monitoring Console host.
As root, restart the common agent container on the host where Application Server resides. For example:
/usr/sbin/cacaoadm start |
Then go to the host where Monitoring Console resides and restart the common agent container. For example:
If common agent container is already running, stop it, then start it with these commands.
On Solaris OS:
/usr/sbin/cacaoadm stop /usr/sbin/cacaoadm start |
On Linux :
/opt/sun/cacao/bin/cacaoadm stop /opt/suncacao/bin/cacaoadm start |
This can occur when you deploy an Application Server sample that uses Java DB after running the default Application Server command to restart Java DB (asadmin stop-database then asadmin start-database). Portal Server samples are no longer be accessible.
Suggested Fix. There are a number ways to approach this problem
Do not stop Java DB.
If Java DB was stopped, restart Java DB with the following command allowing the Application Server database to be created in an alternate location.
Solaris OS: /asadmin start-database --dbhome /var/opt/SUNWportal/derby
Linux: /asadmin start-database --dbhome /var/opt/sun/portal/derby
If you want the database to be located in the default location, start a second instance of Java DB using a non-default port, then specify the correct Derby port in the Application Server samples common.properties file. For example: asadmin start-database --dbport 1528
The tables in this section provide various quick tips on troubleshooting product component problems, including references to useful documentation. This section contains the following subsections:
Topic |
Details |
---|---|
Configuration File |
AMConfig.properties
|
Log and Debug Files |
Log file directory:
Debug file directory:
|
Debug Mode |
Refer to the Auditing Features chapter in the Sun Java System Access Manager 7.1 Developer’s Guide. |
Topic |
Details |
---|---|
Log Files |
Log file directory:
Application Server instance log directory (default location for the initially created instance):
Message log file name: server.log, for each server instance |
Configuration Files |
|
Troubleshooting |
Refer to the Sun Java System Application Server Enterprise Edition 8.2 Troubleshooting Guide. |
Topic |
Details |
---|---|
Log Files |
Installation log file:
|
Troubleshooting |
Topic |
Details |
---|---|
Log Files |
Installation log file:
Broker log file:
|
Troubleshooting |
Refer to the Troubleshooting Problems chapter of the Sun Java System Message Queue 3 2005Q4 Administration Guide. For performance problems, refer to “Analyzing and Tuning a Message Service” in the Sun Java System Message Queue 3 2005Q4 Administration Guide. |
Topic |
Details |
---|---|
Configuration Files |
For Monitoring Console:
|
Log Files |
For Monitoring Console:
For Monitoring Framework:
|
Troubleshooting |
If you cannot access Monitoring Console, refer to Troubleshooting the Monitoring Console in Sun Java Enterprise System 5 Update 1 Monitoring Guide. If you cannot see your monitored components in the Monitoring Console, refer to Troubleshooting the Monitoring Framework in Sun Java Enterprise System 5 Update 1 Monitoring Guide |
Topic |
Details |
---|---|
Debug Files |
Solaris OS: /var/opt/SUNWportal/logs Linux: /var/opt/install/portal/logs Portal Server Desktop debug files: Solaris OS: /var/opt/SUNWam/debug/desktop and /var/opt/SUNWam/debug/desktop.dpadmin.debug Linux: /var/opt/sun/identity/debug/desktop and /var/opt/sun/identity/debug/desktop.dpadmin.debug The dpadmin, par, rdmgr, and sendrdm Portal Server command line utilities have options to generate debugging messages. They are described in the Portal Server Administration Guide. |
Log Files |
Solaris OS: /var/opt/SUNWportal/logs Linux: /var/opt/sun/portal/logs |
Troubleshooting |
Refer to the Sun Java System Portal Server 7.1 Administration Guide. |
Portal gateway debug logs are located in the following directories:
Solaris OS: /var/opt/SUNWportal/debug
Linux: /var/opt/sun/portal/debug and /var/opt/sun/identity/debug/desktop/debug
For Solaris OS, logs for Portal Server services (such as NetFile) are in /var/opt/SUNWam/debug when logging is turned on from the Access Manager Administration Console.
Topic |
Details |
---|---|
Log Files |
Instance log directory:
Message log file name is server.log. |
Configuration File Location |
Solaris OS: /opt/SUNWsrvc-registry/install/install.properties Linux: /opt/sun/srvc-registry/install/install.properties |
Troubleshooting |
Refer to the Service Registry 3.1 Update 1 Administration Guide. |
Linux do not support Sun Cluster components.
Topic |
Details |
---|---|
Log Files |
Default log directory: /var/cluster/logs/install Error messages: /var/adm/messages |
Troubleshooting |
Refer to the Sun Cluster Software Installation Guide for Solaris OS. |
Topic |
Details |
---|---|
Log Files |
The errors log file lists all the errors the server has encountered. The access log file records the information about requests to the server and the responses from the server. For more information, refer to the Sun Java System Web Proxy Server 4.0.5 Administration Guide. |
Configuration File Directory |
For Solaris OS: /opt/SUNWproxy/proxy-instance-name /config For Linux: /opt/sun/webserver/proxy-instance-name /config |
Debug Mode |
You can set the value of the loglevel attribute of the LOG element in the /server-root/proxy-instance-name /config/server.xml file: info, fine, finer, finest. |
Topic |
Details |
---|---|
Log Files |
There are two types of Web Server log files: the errors log file and the access log file. The errors log file lists all the errors a server has encountered. The access log records information about requests to the server and the responses from the server. For more information, refer to the Sun Java System Web Server 7.0 Update 1 Administrator’s Guide These logs are located in the following directories:
If Web Server configuration fails during Configure Now installation, refer to the following logs for additional information:
Admin Server errors logs can be found here:
|
Configuration File Directory |
|
The following information in this guide is also useful for troubleshooting:
Chapter 6, Completing Postinstallation Configuration contains instructions for performing postinstallation configuration.
Chapter 8, Uninstalling contains information on problems that might occur while uninstalling the Java ES software.