This topic describes troubleshooting the installation of the WebSphere Application Server Network Deployment product.
Before you begin
If you are looking for troubleshooting information for the Web server plug-ins for WebSphere Application Server, see Troubleshooting Web server plug-ins installation and removal. This topic does not describe the plug-ins.
Use this topic after installing your WebSphere Application Server product.
If an installation is not successful, use this troubleshooting information to correct the problems.
Why and when to perform this task
The install_root/logs/log.txt file, the install_root/logs/wasprofile/wasprofile_create_profile_name.log file, and the profiles_root/profile_name/logs/pctLog.txt file record installation and profile creation status.
The installer program records the following indicators of success in the logs:
If the error happens early in the installation, look for the log.txt file in the system temporary area. The installation program copies the log from the temporary area to the logs directory at the end of the installation.
Perform the following procedure to troubleshoot an installation.
Steps for this task
During installation, a single entry in the install_root/logs/log.txt file points to the temporary log file, either %TEMP%\log.txt on Windows platforms, or /tmp/log.txt on Linux and UNIX platforms. The installation program copies the file from the temporary directory to the install_root/logs/log.txt location at the end of the installation.
If the installation fails and the install_root/logs/log.txt has only this one pointer to the temporary directory, open the log.txt file in the temporary directory. The log might have clues to the installation failure. Uninstalling creates the install_root/logs/uninstlog.txt file.
Log more information when InstallShield for MultiPlatforms (ISMP) cannot start the Installation wizard.
Verify or troubleshoot the installation if the install_root/logs/log.txt file or the profiles_install_root/profile_name/logs/pctLog.txt file does not contain a record of any problems, but problems exist. If the profiles_install_root/profile_name directory exists, the pctLog.txt file is in the logs directory. If the error happens early in the installation, look for the logs in the system temporary area. The installation program copies the logs from the system temporary area to the logs directory at the end of the installation.
If the profiles_install_root/profile_name directory does not exist, the pctLog.txt file is in the USER_HOME directory and is named .$~pctLog.txt. Issue the env command to display the USER_HOME directory on Linux and UNIX systems. See the environment variable settings on Windows system to display the value of the variable.
install -options fully_qualified_options_response_file_name -silent -log # !fully_qualified_log_file_name @ALL
install -options "/usr/IBM/WebSphere/silentFiles/myresponsefile.txt" -silent -log # !/usr/IBM/WebSphere/myOptionFiles/log.txt @ALL
install -options "/opt/IBM/WebSphere/silentFiles/myresponsefile.txt" -silent -log # !/opt/IBM/WebSphere/myOptionFiles/log.txt @ALL
install.exe -options "C:\IBM\WebSphere\silentFiles\myresponsefile.txt" -silent -log # !C:\IBM\WebSphere\silentFiles\log.txt @ALL
The following examples show how to use the -log parameter when creating a deployment manager profile.
pctAIX.bin -options /usr/IBM/WebSphere/silentFiles/responsefile.pct.NDstandAloneProfile.txt -silent -log # !/usr/IBM/WebSphere/silentFiles/pctlog.txt @ALL
pctLinux.bin -options "/opt/IBM/WebSphere/silentFiles/responsefile.pct.NDstandAloneProfile.txt" -silent -log # !/opt/IBM/WebSphere/silentFiles/log.txt @ALL
Log file names and locations
The following information shows the log files for all of the installable components on the product disc.
Log files for IBM HTTP Server
Windows system log path name | Linux and UNIX operating system log path name |
---|---|
C:\Program Files\IBM HTTP Server\log.txt C:\Program Files\IBM HTTP Server\ihsv6_install.log |
|
Log files for Application Client for WebSphere Application Server
Windows system log path name | Linux and UNIX operating system log path name |
---|---|
|
|
Log | Content | Indicators |
---|---|---|
install_root/logs/log.txt | Logs all installation events |
|
install_root/logs/wasprofile/wasprofile_create_profile_name.log |
|
|
install_root/logs/wasprofile/wasprofile_delete_profile_name.log |
|
|
install_root/profiles/profile_name/logs/pctLog.txt | Logs all profile creation events that occur when using the Profile creation wizard |
|
Description of the wasprofile_create_profile_name.log file
The wasprofile_create_profile_name.log file is an XML file that contains a record of the events that occur during the creation of the last profile.
<record> <date>2004-09-08T11:51:39</date> <millis>1094658699225</millis> <sequence>0</sequence> <logger>com.ibm.ws.profile.WSProfile</logger> <level>INFO</level> <class>com.ibm.ws.profile.WSProfile</class> <method>getRegistryFile</method> <thread>10</thread> <message>Returning registry file at: C:\NDV6\IBM\WebSphere\AppServer\properties\profileRegistry.xml </message> </record>
Log files created during the creation of the Application Server profile
This log is not created during installation of the product.
Log files for the Migration wizard and the migration tools
See Troubleshooting migration for a description of log files and other troubleshooting information.
Log files for Web server plug-ins for WebSphere Application Server
See Troubleshooting Web server plug-ins installation and removal for a description of log files and other troubleshooting information.
IBM Support sometimes queues work for customers and provides test or debugging fixes. A common location for the fixes is in the install_root/classes directory.
By default, the install_root/classes directory is picked up first in the WebSphere Application Server class path to let it override other classes.
Putting a fix in the directory lets you verify that the fix does indeed solve your problem. After verifying that the fix solves the problem, you are supposed to delete the fix from the install_root/classes directory to return the system to a working state.
If you do not remove such fixes from the install_root/classes directory, you can experience errors.
install -is:javaconsole
install -is:javaconsole > captureFileName.txt 2>&1
install.exe -is:javaconsole
install -is:javaconsole > drive:\captureFileName.txt
install -W Setup.product.install.logAllEvents="true"
install -W Setup.product.install.logAllEvents="true"
If no Java process exists or if the message does not appear, examine the same logs for any miscellaneous errors. Correct any errors and retry.
Press Ctrl+Alt+Delete and
type T to open the Task Manager. Click the Processes tab and
the Image Name column header to sort by image name. Look for processes
named java.exe.
ps -ef | grep java
If no Java process exists or if the message does not appear, examine the same logs for any miscellaneous errors. Correct any errors and try again to start the deployment manager.
Test your environment by starting your Application Server, your Web server, and using the snoop servlet with an IP address.
Use a command window to change the directory to the IBM HTTP Server installed image, or to the installed image of your Web server. Issue the appropriate command to start the Web server, such as these commands for IBM HTTP Server:
To start the IBM HTTP Server from the command line:
The HTTP Transport port is 9080 by default and must be unique for every profile. The port is associated with a virtual host named default_host, which is configured to host the installed DefaultApplication and any installed Samples. The snoop servlet is part of the DefaultApplication. Change the port to match your actual HTTP Transport port.
Either Web address should display the Snoop Servlet - Request/Client Information page.
"Could not connect to IHS Administration server error"
The HTTP Admin port is 9060 by default and must be unique for the administrative console of each stand-alone Application Server. The port is associated with a virtual host named admin_host, which is configured to host the administrative console, which is installed by default as a system application. Change the port to match your actual HTTP Admin port.
If you have problems accessing the administrative console after installation, check the installAdminConsole.log file for a failure indication. Clean up the system temporary directory and reinstall the administrative console using the wsadmin scripting facility.
The server starts. The administrative console starts. You can access the administrative console through the browser. The administrative console accepts your login.
Click System administration > Nodes > Add Node and follow the wizard. The default SOAP port for the Application Server is 8880. You can use localhost as the value of the Host name field, if the Application Server is on the same machine.
Tool information is being logged in file C:\Program Files\IBM\WebSphere\AppServer\profiles\Profile01\logs\addNode.log Begin federation of node AppServer01 with Deployment Manager at localhost:8879. Successfully connected to Deployment Manager Server: localhost:8879 Servers found in configuration: Server name: server1 Stopping all server processes for node AppServer01 Creating node agent configuration for node: AppServer01 Reading configuration for node agent process: nodeagent Adding node AppServer01 configuration to cell: AdvancedDeploymentCell Performing configuration synchronization between node and cell. Launching node agent process for node: AppServer01 Node agent launched. Waiting for initialization status. Node agent initialization completed successfully. Process ID is: 3012 Node AppServer01 has been successfully federated.The last message is an indicator of success. A second Java process is running, which is the nodeagent process. The stdout.log file and stderr.log file in the node_name directory each contain relevant messages.
By default, the Java 2 SDK caches the IP address for the domain name service (DNS) naming lookup. After resolving the host name successfully, the IP address stays in the cache. By default, the cache entry remains forever.
This default IP caching mechanism can cause problems, as described in the following problem scenarios.
Problem scenario 1
Suppose the Application Server at host1.ibm.com has an initial IP address of 1.2.3.4. When a client at host2.ibm.com conducts a DNS lookup of host1.ibm.com, the client stores the 1.2.3.4 address in the cache. Subsequent DNS name lookups return the cached value, 1.2.3.4.
The cached value is not a problem until the host1.ibm.com IP address changes, to 5.6.7.8, for example. The client at host2.ibm.com does not retrieve the current IP address, but always retrieves the previous address from the cache.
If this scenario occurs, the client cannot reach host1.ibm.com unless you stop and restart the client process.
Problem scenario 2
Suppose the Application Server at host1.ibm.com has an initial IP address of 1.2.4.5. Although the IP address of the application server does not change, a network outage can record an exception code as the IP address in the cache, where it remains until the client is restarted on a working network.
For example, if the client at host2.ibm.com disconnects from the network because of an unplugged cable, the disconnected lookup of the Application Server at host1.ibm.com fails. The failure causes the IBM Developer Kit to put the special exception code entry into the IP address cache.
Subsequent DNS name lookups return the exception code, which is java.net.UnknownHostException.
IP address caching and WebSphere Application Server process discovery
If you change the IP address of a federated WebSphere Application Server node, processes running in other nodes cannot contact the changed node until you stop and restart them.
If a deployment manager process starts on a disconnected node, it cannot communicate with cell member processes until you stop and restart the deployment manager process. For example, plugging in an unplugged network cable does not restore proper addresses in the IP cache until the deployment manager process is restarted.
Using the IP address cache setting
You can always stop and restart a deployment manager process to refresh its IP address cache. However, this process might be expensive or inappropriate.
The networkaddress.cache.ttl (public, JDK1.4) and sun.net.inetaddr.ttl (private, JDK1.3) parameters control IP caching. The value is an integer that specifies the number of seconds to cache IP addresses. The default value, -1, specifies to cache forever. A value of zero (0) is a specification to never cache.
Using a zero (0) value is not recommended for normal operation. If you do not anticipate network outages or changes in IP addresses, use the cache forever setting. The never caching setting introduces the potential for DNS spoofing attacks.
For more information about the Java 2 SDK
The Java 2 SDK, Standard Edition 1.4 Web site at http://java.sun.com/j2se/1.4/docs/guide/net/properties.html describes the private sun.net.inetaddr.ttl property, which works in both Java 2 SDK, Standard Edition 1.3 (WebSphere Application Server V5.0.0, V5.0.1, and V5.0.2) and Java 2 SDK, Standard Edition 1.4 (WebSphere Application Server V5.1 and V6).
Result
This procedure results in using some simple procedures to debug errors that might be occurring in the installation.
What to do next
The Troubleshooting installation problems contains more detailed debugging and reporting instructions. See Installation component troubleshooting tips for more information about troubleshooting the installation.
For current information available from IBM Support on known problems and their resolution, see the IBM Support page.
IBM Support has documents that can save you time gathering the information that you need to resolve a problem. Before opening a PMR, see the IBM Support page.