Troubleshoot the installation

 

If you did not receive the Successful installation message, troubleshoot the installation, as described below.

  1. Run the installation verification test (IVT). Check...

    $WAS_HOME/logs/ivt.log
    ...file for a summary of test results.

  2. Check log files

    Description Filename
    Main install $WAS_HOME/logs/log.txt
    /tmp/log.txt
    Uninstall $WAS_HOME/logs/uninstlog.txt
    Embedded messaging prerequisites mq_prereq.log
    IBM HTTP Server ihs_log.txt
    Embedded messaging installation mq_install.log
    Embedded messaging configuration createMQ.node.server.log
    Default Application installDefaultApplication.log
    Samples Gallery installSamples.log
    Administrative console installAdminConsole.log
    Migration tools WASPostUpgrade.log

  3. Turn on tracing if the installation logs do not contain enough information to determine the cause of the problem.

    Report the stdout and stderr logs to the console window, by adding the -is:javaconsole parameter to the Install.exe or install command... 

    install -is:javaconsole

    ...or capture the stream to a file with... 

    install -is:javaconsole > captureFileName.txt 2>&1

  4. Capture additional information to a log of your choice with the -is:log filename option.

  5. Turn on additional installation logging... 

    install -W Setup.product.install.logAllEvents="true"

    If you install on an AIX 5.1 system, with maintenance level 2, it is possible that the Web-based system manager, a standard component of AIX systems, already uses port 9090. When starting the server you get information that port 9090 is already in use. To resolve the conflicting port use, change the port assignment for the HTTP_TRANSPORT_ADMIN port in the server.xml file. The file path is 

    /u../WAS51/appserver/config/cells/cell/nodes/node/servers/server/server.xml

  6. Use the First Steps tool or the command line method to start the Application Server. To start the server from the command line...

    $WAS_HOME/bin/startServer.sh server

    If you enable security, specify the -user and the -password parameters of the command.

  7. Verify whether the server starts and loads properly, by looking for a running Java process and the Open for e-business message in the SystemOut.log and SystemErr.log files. If there is no Java process or the message does not appear, examine the same logs for any miscellaneous errors. Correct any errors and retry. You can find the SystemOut.log and SystemErr.log files in the $WAS_HOME/logs/server

  8. Refer to the plug-in configuration documentation, if you have installed plug-ins and the Web server does not come up properly.

  9. Start the Snoop servlet.

    1. Start the Application Server.

    2. Start the IBM HTTP Server or the Web server you are using. Use a command window to change 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: Access the apache and apachectl commands in the IBMHttpServer/bin directory.

      ./apachectl start

    3. Point your browser to URL: http://localhost:9090/snoop to test the internal HTTP transport provided by the Application Server. Point your browser to http://localhost/snoop to test the Web server plug-in.

    4. Verify that Snoop is running.Either URL should display the Snoop Servlet - Request/Client Information page.

  10. Start the WAS administrative console.

    1. Start the Application Server.
    2. Point your browser to URL: http://localhost:9090/admin.
    3. Type any ID and click OK at the administrative console window.

    The server starts. The administrative console starts. You can access the administrative console through the browser. The administrative console accepts your login.

  11. Resolve any IP address caching problems.

    By default, the Java 2 SDK caches the IP address for the 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 below.

 

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, it 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 appserver 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 cycled 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.UnknowHostException.

 

Using the IP address cache setting

You can always stop and restart a deployment manager process to refresh its IP address cache. However, this 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 0 specifies to never cache.

Using a zero value is not recommended for normal operation. If you do not anticipate network outages or changes in IP addresses, use the cache forever setting. Never caching introduces the potential for DNS spoofing attacks.

 

For more information

The Java 2 SDK, Standard Edition 1.4 Web site describes the private sun.net.inetaddr.ttl property, which works in both Java 2 SDK, Standard Edition 1.3 (WAS V5.0.0, V5.0.1, and V5.0.2) and Java 2 SDK, Standard Edition 1.4 (WebSphere Application Server V5.1).

For current information available from IBM Support IBM Support PMR page.

 

See Also

Troubleshooting or problem determination
addNode command
removeNode command
startNode command
stopNode command
startServer command
serverStatus command
stopServer command
startManager command
stopManager command