Troubleshooting installation

This topic describes troubleshooting the installation of the WebSphere® Application Server product.

Before you begin

If you are looking for troubleshooting information for WebSphere Application Server products on IBM® i platforms, see IBM i installation troubleshooting tips. This topic does not describe IBM i systems.

Use this topic after installing your WebSphere Application Server product.

A successful installation of a WebSphere Application Server product installs the core product files and creates the server1 Application Server.

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

About 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

    The operation was a success.

  • INSTCONFPARTIALSUCCESS

    The operation was partially successful. Refer to the log for more details.

  • INSTCONFFAILED

    The operation failed. Refer to the log for more details.

Procedure

  1. Run the installation verification test (IVT).
  2. 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.

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

    The app_server_root/logs/install/log.txt file and the app_server_root/logs/manageprofiles/profile_name_create.log 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.
    • user_home/waslogs/log_date_stamp.time_stamp.txt if installation finishes but is unsuccessful or for some other reason cannot be copied to app_server_root/logs/install/log.txt
    • user_home/waslogs/log.txt if installation is interrupted
    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/install/log.txt file points to the temporary log file, either %TEMP%\log.txt on Windows® platforms, or /tmp/log.txt on platforms such as AIX® or Linux®. The installation program copies the file from the temporary directory to the app_server_root/logs/install/log.txt location at the end of the installation.

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

    Log more information when InstallShield MultiPlatform (ISMP) cannot start the installation wizard.

    Certain events can prevent the installer from starting the installation wizard. Such an event is not enough disk space to launch the installation wizard, for example. If your installation fails and there is no information in the installation logs, use the -log parameter to record entries for events that cause the installer program to fail to start the installation wizard. The syntax of the install command for logging such events is:
    install  -options fully_qualified_options_response_file_name               
             -silent
             -log # !fully_qualified_log_file_name  @ALL 

    Log file names and locations

    The following information shows the log files for all of the installable components on the product disk.

    Log files for IBM HTTP Server

    Table 1. Installation log locations when installing IBM HTTP Server.

    The following table shows the installation log locations when installing IBM HTTP Server.

    Windows system log path name Log path name on operating systems such as AIX or Linux

    Log files for Application Client for WebSphere Application Server

    Table 2. Installation log locations when installing the Application Client for WebSphere Application Server.

    The following table shows the installation log locations when installing the Application Client.

    Windows system log path name Operating system log path name on systems such as AIX or Linux
       

    Installation log files for WebSphere Application Server

    Table 3. Installation, profile creation, and profile deletion logs for WebSphere Application Server.

    The following table shows the installation logs, content, and indicators of success and failure for the product.

    Log Content Indicators
    app_server_root /logs/install/log.txt Logs all installation events Return code Meaning
    0 Success
    1 Failure
    2 Partial Success
    user_data_root/profileRegistry/logs/manageprofiles/create.log
    • Traces all events that occur during the creation of the named profile
    • Created when using the Profile Management Tool or the manageprofiles command
    INSTCONFFAILED
    Total profile creation failure.
    INSTCONFSUCCESS
    Successful profile creation.
    INSTCONFPARTIALSUCCESS
    Profile creation errors occurred but the profile is still functional. Additional information identifies the errors.
    app_server_root/logs/install/installconfig.log
    • Logs the activities of ANT configuration scripts that run at the end of the installation procedure
    Configuration action failed:
    Unsuccessful ANT script configuration.
    Configuration action succeeded:
    Successful ANT script configuration.

    Description of the profile_name_create.log file

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

    Other log files

    Table 4. Profile logs for WebSphere Application Server.

    In addition to the logs created within the core product files, the following logs are created in the profile_root/logs and the app_server_root\logs\manageprofiles\profile_name directories.

    Log Description
    AboutThisProfile.txt General information about the profile
    activty.log Compiled activity log from various installation activities
    collect_metadata.log Collects metadata information about managed objects in the system to evaluate and prevent potential installation conflicts
    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
    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
    Table 5. Server logs for WebSphere Application Server.

    The following logs are created in the profile_root/logs/profile_type directory:

    Log Description
    startServer.log Log of start server events
    SystemErr.log Record system errors
    Table 6. First failure data capture logs for WebSphere Application Server.

    The following logs are created in the profile_root/logs/ffdc directory:

    Log Description
    profile_type_exception.log First failure data capture log for server1 errors

    Log files for Web server plug-ins for WebSphere Application Server

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

    The app_server_root/logs/install/instconfig.log file indicates ANT configuration problems that could prevent the product from working correctly.

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

  6. 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:
      Avoid trouble: Although the usage of -is:javaconsole is supported, the usage of -console, for example install -console, is not supported.gotcha
    • Capture additional information to a log of your choice with the -is:log file_name option.
  7. Use the command line method to start the application server.
  8. 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 profile_root/logs/server1 (platforms such as AIX or Linux) or profile_root\logs\server1 (Windows platforms) directory in an Application Server profile.

  9. Start the Snoop servlet to verify the ability of the Web server to retrieve an application from the Application Server.

    Test your environment by starting your Application Server, your Web server, and using the snoop servlet with an IP address.

    1. Start the Application Server.
      Change directories to the profile_root/bin directory and run the startServer command:
      • startServer server1
    2. Start the IBM HTTP Server or the Web server that you are using.

      Use either the 2001 page or use the STRTCPSVR SERVER(*HTTP) HTTPSVR(instance_name ) command to start the IBM HTTP Server.

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

      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.

    4. Verify that snoop is running.

      Either Web address should display the Snoop Servlet - Request/Client Information page.

    5. Remote IBM HTTP Server only:
      Automatic propagation of the plug-in configuration file requires the IBM HTTP administrative server to be up and running. If you are managing an IBM HTTP Server using the WebSphere Application Server administrative console, the following error might display:
      "Could not connect to IHS Administration server error"
      Perform the following procedure to correct the error:
      1. Verify that the IBM HTTP Server administration server is running.
      2. Verify that the Web server host name and the port that is defined in the WebSphere Application Server administrative console matches the IBM HTTP Server administration host name and port.
      3. Verify that the fire wall is not preventing you from accessing the IBM HTTP Server administration server from the WebSphere Application Server administrative console.
      4. Verify that the user ID and password that is specified in the WebSphere Application Server administrative console under remote managed, is created in the admin.passwd file, using the htpasswd command.
      5. If you are trying to connect securely, verify that you export the IBM HTTP Server administration server keydb personal certificate into the WebSphere Application Server key database as a signer certificate. This key database is specified by the com.ibm.ssl.trustStore directive in the sas.client.props file in the profile where your administrative console is running. This consideration is primarily for self-signed certificates.
      6. If you still have problems, check the IBM HTTP Server admin_error.log file and the WebSphere Application Server logs (trace.log file) to determine the cause of the problem.
  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 standalone 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. 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.

    For more information about the Java 2 SDK

Results

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

What to do next

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.




In this information ...


IBM Redbooks, demos, education, and more

(Index)

Use IBM Suggests to retrieve related content from ibm.com and beyond, identified for your convenience.

This feature requires Internet access.

Task topic    

Terms of Use | Feedback

Last updated: Oct 21, 2010 12:08:31 PM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=compass&product=was-base-iseries&topic=tins_trouble
File name: tins_trouble.html