WebSphere Application Server Network Deployment, Version 6.0.x     Operating Systems: AIX, HP-UX, Linux, Solaris, Windows

Troubleshooting installation

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.

The successful installation of the Network Deployment product is a two-part process:
  • The first step is using the installation wizard to install a shared set of core product files.
  • The second step is using the Profile Creation wizard to create a deployment manager profile, an Application Server profile, or a custom profile.

If an installation is not successful, use this troubleshooting information to correct the problems.

Why and when to perform this task

Use this topic to help interpret the log files and diagnose possible problems when the installation is unsuccessful.

The installer program records the following indicators of success in the logs:

  • INSTCONFSUCCESS
  • INSTCONFPARTIALSUCCESS
  • INSTCONFFAILED

Steps for this task

  1. Run the installver command to calculate and compare checksums for all installed components to the bill of materials list for the product.

    See Verifying checksums of installed files for more information.

    Compare the output from the installver command to the installation log files that are described in the next step.

  2. Check the installation log files for errors after installing:

    The app_server_root/logs/log.txt file, the app_server_root/logs/wasprofile/wasprofile_create_profile_name.log file, and the profile_root/logs/pctLog.txt file record installation and profile creation status.

    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.

    During installation, a single entry in the app_server_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 app_server_root/logs/log.txt location at the end of the installation.

    If the installation fails and the log.txt file 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 app_server_root/logs/uninstlog.txt file.

    Attention:

    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

    The following table shows the installation log locations when installing IBM HTTP Server.
    Table 1. Installation log locations when installing IBM HTTP Server
    Windows system log path name Linux and UNIX operating system log path name

    [Windows]C:\Program Files\IBM HTTP Server\log.txt

    [Windows]C:\Program Files\IBM HTTP Server\ihsv6_install.log

    [AIX]/usr/IBMHttpServer/ log.txt

    [AIX]/usr/IBMHttpServer/ ihsv6_install.log

    [Linux][HP-UX][Solaris]/opt/IBMHttpServer/ log.txt

    [Linux][HP-UX][Solaris]/opt/IBMHttpServer/ ihsv6_install.log

    Log files for Application Client for WebSphere Application Server

    The following table shows the installation log locations when installing the Application Client.
    Table 2. Installation log locations when installing the Application Client for WebSphere Application Server
    Windows system log path name Linux and UNIX operating system log path name

    [Windows]C:\Program Files\IBM\WebSphere\ AppClient\logs\WAS.Client.install.log

    [AIX]/usr/IBM/WebSphere/AppClient/logs/WAS.Client.install.log

    [Linux][HP-UX][Solaris]/opt/IBM/WebSphere/AppClient/logs/WAS.Client.install.log

    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.

    In addition to the date tag at the beginning of the file, other tags of interest in the log files include the sequence tag, the level tag, the method tag, and the message tag:
    • The sequence tag records the sequence of events that occur during the creation of the profile.
    • The level tag is an early indicator of event status:
      INFO
      Indicates a normal event.
      WARNING
      Indicates an event that occurred with errors that do not prevent the creation of the profile.
      ERROR
      Indicates an event that prevents the creation of the profile.
    • The method tag indicates the name of the routine that recorded the event.
    • The message tag describes the event and contains any data returned by the method.
    The following stanza is an example of how an event is documented in each log file:
    <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:\IBM\WebSphere\AppServer\properties\profileRegistry.xml
      </message>
    </record>

    Log files created during the creation of the Application Server profile

    In addition to the logs created within the core product files, the following logs are created in the profile_root/logs directory.

    Both the Profile Creation wizard and the wasprofile command create the log when creating an application server profile:

    activity.log
    Compiled activity log from various installation activities
    amjrte_config.log
    Tivoli Access Manager configuration log for its Java Runtime Environment
    collect_metadata.log
    Collects metadata information about managed objects in the system to evaluate and prevent potential installation conflicts
    createDefaultServer.log
    A log from wsadmin recording the creation of the server1 process in the default profile
    createshortcutforprofile.log
    Windows tool log for creating menu entries and shortcuts
    defaultapp_config.log
    JACL script log from configuring default application resources
    defaultapp_deploy.log
    Application DefaultApplication installation log
    node_name Service.log
    Start and stop events for server1
    filetransfer_config.log
    Application filetransfer installation log
    hamanager_config.log
    Configuration log for the high availability application
    ivt_config.log
    Application ivtApp installation log
    mejb_config.log
    Application ManagementEJB installation log
    pctLog.txt
    Log created when using the Profile Creation wizard to create a profile.

    This log is not created when using the wasprofile command directly.

    This log is not created during product installation.

    query_config.log
    Application Query installation log
    samples_config.log
    Configuration log for the PlantsByWebSphere Samples application
    samples_install.log
    Installation log for the SamplesGallery and PlantsByWebSphere Samples applications
    scheduler.cal_config.log
    Application SchedulerCalendars installation log
    SIBDefineChains.log
    Creation log for service integration bus endpoints, inbound channels and channel chains, outbound thread pool, and outbound channel and channel chains
    SIBDeployRA.log
    Deployment log for the service integration bus function
    webui_config.log
    Application administrative console installation log
    winservice_config.log
    Service log for the Windows service created for server1
    The following logs are created in the profile_root/logs/server1 directory:
    startServer.log
    Log of start server events
    stopServer.log
    Log of stop server events
    SystemErr.log
    Record system errors
    SystemOut.log
    Log of all activity within the system
    trace.log
    Log of all traced events within the system
    The following logs are created in the profile_root/logs/ffdc directory:
    server1_exception.log
    First failure data capture log for server1 errors
    server1_numeric_identifier.txt
    Any first failure data capture logs

    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.

  3. Determine whether the installation problem is caused by a failing ANT script.

    The app_server_root/logs/instconfig.log file indicates ANT configuration problems that could prevent the product from working correctly. The log file is not present on Linux systems and UNIX systems.

    See Diagnosing a failing ANT configuration script for a description of how to manually diagnose and fix an ANT script problem.

  4. Verify that no files exist in the app_server_root/classes directory.

    IBM Support sometimes queues work for customers and provides test or debugging fixes. A common location for the fixes is in the app_server_root/classes directory.

    By default, the app_server_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 app_server_root/classes directory to return the system to a working state.

    If you do not remove such fixes from the app_server_root/classes directory, you can experience errors.

  5. Uninstall the product, if possible, and reinstall after turning on tracing if the error 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 command:
      • [Linux][UNIX]
        install -is:javaconsole
        Capture the stream to a file with the following commands:
        install -is:javaconsole > captureFileName.txt 2>&1
      • [Windows]
        install.exe -is:javaconsole
        Capture the stream to a file with the following commands:
        install -is:javaconsole > drive:\captureFileName.txt
    • Capture additional information to a log of your choice with the -is:log file_name option.
    • Turn on additional installation logging by passing the -W Setup.product.install.logAllEvents="true" parameter to the install command:
      • [Linux][UNIX]
        install -W Setup.product.install.logAllEvents="true"
      • [Windows]
        install -W Setup.product.install.logAllEvents="true"
  6. If you have successfully created an application server profile, use the First steps console or the command line method to start the Application Server.
  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 no Java process exists or if 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 following platform-specific directory:
  8. Use the First steps console or the command line method to stop the Application Server, if it is running, and to start the deployment manager if one exists.
    To stop server1 from the command line: If you enable security, specify the -user and the -password parameters of the command.
    To start the deployment manager from the command line:
  9. Verify that the server starts and loads properly by looking for a running Java process and the Server dmgr open for e-business message in the profile_root/logs/server_name/SystemOut.log file.

    [Windows]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.

    [Linux][UNIX]Open a command window and issue the top command to see a display of running processes. If the top command is not available on your UNIX system, use the ps command:
    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.

  10. Start the WebSphere Application Server administrative console.
    1. Start the Application Server.
    2. Point your browser to http://localhost:9060/ibm/console.

      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.

    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. Federate the base Application Server into the cell. To add the base Application Server into the cell:
    • Deployment manager administrative console method:

      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.

    • Command-line method assuming the SOAP port of the dmgr is 8879:
    If you enable security, specify the -user and the -password parameters of the command.
  12. Verify that the Application Server was incorporated into the cell. The command window displays a sequence of messages when you issue the addNode command:
    Tool information is being logged in file
               profile_root\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.
  13. Resolve any IP address caching problems.

    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 Platform Standard Edition (J2SE) 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 Platform Standard Edition (J2SE) 1.4.2 (WebSphere Application Server V5.1 and V6.0).

Result

This procedure results in debugging errors that might occur during installation.

What to do next

The 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.




Sub-topics
Troubleshooting Web server plug-ins installation and removal
Installation component troubleshooting tips
Installation problems
Installation either completes with errors or warnings, or hangs
Diagnosing a failing ANT configuration script
Problems installing or starting Apache or IBM HTTP Server
Messages issued during installation and profile creation
Task topic    

Terms of Use | Feedback

Last updated: Dec 11, 2005 4:07:15 PM CST
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/tins_trouble.html

© Copyright IBM Corporation 2004, 2005. All Rights Reserved.
This information center is powered by Eclipse technology. (http://www.eclipse.org)