Troubleshooting Web server plug-ins installation and removal


 

+

Search Tips   |   Advanced Search

 

  1. Troubleshooting plug-ins installation
  2. Troubleshooting plug-ins removal
  3. Miscellaneous messages, tips, and hints

 

Log files for Web server plug-ins for WAS

The following log files are in...

PLUGINS_ROOT/logs/install

File name Description
log.txt ISMP events. Also describes if installation was local or remote. Messages at the end of the file indicate whether manual configuration steps are required to complete the installation.
masterConfigurationLog.txt Install configuration events
installGSKit.log GSKit install events
installWebServerPlugin.log Plug-in install events.

WebServer can have one of the following values:

  • APACHE
  • IHS
  • IIS
  • SUNONE
  • DOMINO

configure_WebServer_webserver.log Plug-in configuration events.

 

Troubleshooting plug-ins installation

  1. Are you seeing "Did not replace" errors in the installation log?

    The Web server Plug-ins installer is an Install Shield for Multiplatforms (ISMP) wizard. The wizard uses the vpd.properties file or the native operating system registry to determine if the plug-ins are installed. If we do not use the uninstaller program for the plug-ins, neither the vpd.properties file nor the operating system registry is updated properly. We might see a PLUGINS_ROOT /logs/install/log.txt with content similar to the following example:

    Plugin.Install, com.installshield.product.service.product.
       PureJava ProductServiceImpl$InstallProduct, msg1, 
       Did not replace installed object (IBM WebSphere Application 
       Server - Plugins) with object (IBM WebSphere Application 
       Server - Plugins) Plugin.Install, ... msg1, Did not replace installed object 
       (WebServer Plugin Binaries and Configurations) with 
       object (WebServer Plugin Binaries and Configurations) Plugin.Install... Did not replace installed object (GSKit) with object (GSKit) Plugin.Install... Did not replace installed object (LAP Component) with 
       object (LAP Component) Plugin.Install...Did not replace installed object (WebServer Plugin 
       Binaries) with object (WebServer Plugin Binaries) Plugin.Install... Did not replace installed object (Additional Bytes  smart man   for non-HP) with object (Additional Bytes for non-HP) Plugin.Install... Did not replace installed object (GSKit) with object (GSKit) Plugin.Install... Did not replace installed object (Standalone JDK) 
       with object (Standalone JDK)
    

    These messages are informational only and do not indicate that the installation has failed. They only indicate that we have not run the uninstaller on an existing installation of the Plug-ins before attempting to reinstall into that same directory.

    To avoid such messages in the future, use the uninstaller program in the PLUGINS_ROOT/uninstPlugin directory to uninstall the Web server Plug-ins. Do not delete the PLUGINS_ROOT directory to uninstall the plug-ins without running the uninstaller program first.

  2. Does the installation image have the proper directories? The directories in bold are required for a successful installation of the plug-ins:

    • parent_directory/WAS
    • parent_directory/IHS
    • parent_directory/plugin
    • parent_directory/AppClient
    • parent_directory/JDK
    • parent_directory/GSKit

    The parent_directory variable is the directory where we can unpack the images. All of the directories in the list must have the same parent directory.

    If the directories are not present, or if the directories are empty, download a new installation image or discuss WAS CD that we are using with someone who is knowledgeable about its creation. The IBM product discs are certified.

    Reinstall using the IBM product disc.

 

Symptoms that can occur when the JDK directory is missing or is not used:

If...

PLUGINS_ROOT/logs/install/log.txt

...records the following errors, the installer program did not use the correct Java 2 SDK, which is in the JDK directory on the installation image:

Plugin.Install, com.ibm.ws.install.ni.ismp.actions.
    ISMPComponentizedFileRepositoryDeployAction, msg1, 
    Processing component: prereq.jdk  Plugin.Install, com.ibm.ws.install.ni.ismp.actions.
    ISMPComponentizedFileRepositoryDeployAction, err, 
    Component not found: prereq.jdk  Plugin.Install, com.ibm.ws.install.ni.ismp.actions.
    ISMPComponentizedFileRepositoryDeployAction, err, 
    ComponentNotFoundException.message 

The installation program can pick up another Java 2 SDK 1.4 on the system when running from the command prompt in terminal window that already has set the Java 2 SDK for the environment. Another way to point the installation program to a particular SDK is with the -is:javahome option for the Install Shield for Multiplatforms (ISMP) wizard.

In either case, the JDK directory on the installation image is not being used. When the installation attempts to install the prereq.jdk component, the wizard cannot find the JDK directory and throws the error in...

PLUGINS_ROOT/logs/install/log.txt

Verify the cause of the error by examining the CURRENT_WORKING_DIRECTORY value and the JAVA_INSTALL_PATH value in the log.txt file.

The working directory value is typically the CD_root/plugin directory. An erroneous Java path might be non_CD_root/java/jre.

The correct Java path is...

CD_root/JDK/repository/prereq.jdk/java/jre

In such a case:

  1. Verify that the JDK directory is on WAS ND disc.
  2. Close the current command window.
  3. Open a new command window.
  4. Change directories to the plugin directory on WAS disc.
  5. Restart the installation: ./install

 

Symptoms that occur when the GSKit directory is missing:

If the JDK directory is present, but the GSKit directory is not present, the installation is only partially successful, as shown in the logs by the INSTCONFPARTIALSUCCESS indicator.

The log file...

PLUGINS_ROOT/logs/install/masterConfigurationLog.txt

...shows that the 99SGSKitInstall.ant script failed to run. Complete the full installation by manually installing GSKit.

The log file...

...shows the command to use for the manual installation in the GSKIT 7 entry.

  • Is there any sign that the installation occurred?

    If not, look for the temporaryPluginInstallLog.txt file in the temporary directory of the user who installed the plug-ins.

    For example...

      /tmp/temporaryPluginInstallLog.txt

    ...might exist if the root user installed the plug-ins on a system such as AIX or Linux.

    This log is of particular interest after a silent installation. Suppose that the silent installation responsefile.txt file has incorrect entries. The installation cannot succeed. The cause of the problem is recorded in the temporaryPluginInstallLog.txt file.

    If the responsefile.txt does not pass validation, the failure is logged as an INSTCONFFAILED entry. The installation does not occur. Correct the failure and run the silent installation again.

    See the plug-ins response file topic for information about editing the file properly. We might have to start with a new copy of the file that is on WAS disc if we cannot get the copy to work.

  • Does a local installation attempt result in an INSTCONFPARTIALSUCCESS status, reporting a 98SConfigureWebserverDefinition failure in log.txt?

    The plugin installation log file shows a code of INSTCONFPARTIALSUCCESS, and the following error message is found in...

    This message states that the installation process was successful, but one of the configuration scripts responsible for configuring the plug-ins failed to complete. In this case, the name of the script which failed to complete is 98SConfigureWebserverDefinition.

    Config action failed: 98SConfigureWebserverDefinition - install_root\properties\version\nif\config\install\ 98SConfigureWebserverDefinition.ant
    Current install/uninstall process is successful. Process type is: install

    This issue occurs under the following conditions:

    • WAS is installed on the same system on which the plugin is being installed.

    • The plug-ins are being installed in local configuration mode.

    • The existing appserver profile, specified in the installation options for the plug-ins, is installed to a location outside of the appserver.

      In other words, the specified profile is not in the default profile location in APP_ROOT/profiles/profile_name. This might occur in IBM products which extend the appserver as part of their installation, like WebSphere Portal Server for example.

    Although the plug-ins installation is intact, the existing appserver is not automatically configured to use the new plug-ins. There are two options to resolve the problem:

    • Uninstall and reinstall the plug-ins in remote mode, then manually invoke the configuration script. Even though the appserver is on the same machine as the plug-ins, we can still run the installation in remote mode.

    • Keep the existing plug-ins, and manually invoke the configuration script as indicated on step 20 and afterwards in the remote configuration topic.

  • Does the installation result in an INSTCONFPARTIALSUCCESS status?

    1. Look for errors in the log.txt file.

    2. Look for an entry in the log.txt file that shows the location of the masterConfigurationLog.txt file.

    3. Edit the masterConfigurationLog.txt file.

    4. Starting at the end of the file, scan towards the front of the file looking for configuration scripts that could not run. For example, the following stanza shows a configuration script that could not run:

      <record>
          <date>2004-10-08T10:31:43</date>
          <millis>1097245903200</millis>
          <sequence>189</sequence>
          <logger>com.ibm.ws.install.configmanager.ConfigManager</logger>
          <level>INFO</level>
          <class>com.ibm.ws.install.configmanager.ConfigManager</class>
          <method>dumpNonFatalFailedActionsInfoToLogFile</method>
          <thread>10</thread>
          <message>This action failed to execute:
            /Plugins/properties/version/install/plugin/7.0.0.0/config/full/install/99SGSKitInstall.ant
          </message>
      </record>
      

    5. A configuration script that fails to run is likely the cause of a partially successful installation status. To debug the example, look at the installGSKit.log, which is the log file for GSKit. Look for signs of a failed installation to determine if we can correct the problem.

     


    Log files and recovery procedures


     

    98SConfigureWebserverDefinition.ant

    Log file Recovery

    configureWebServer_webserver.log

    For example, the file might be named:

    configure_IHS_webserver.log

    Logs the Web server definition creation.

    1. If the Web server definition partially exists, delete the Web server definition.

    2. Run the Web server definition script manually. The Web server definition is referenced in the script. The script is in...

      PLUGINS_ROOT/bin

      ...with a name similar to...

        configureWebServer.sh

     

    99SBootStrapPluginsSunOne.ant

    Log file Recovery
    installSunOnePlugin.log

    1. If the error is due to plugin-cfg.xml not existing, investigate why this file is not present.

    2. If the error is due to the Web server definition creation failing, address this as discussed under the 98SConfigureWebserverDefinition.ant description.

    3. If the Web server configuration files do not update, investigate the files to verify that they exist and that the file permissions are correct.

    • Manually configure the Web server

    • Rerun the Plug-ins installation wizard. Select the existing plug-ins installation root directory. Doing so results in the Web server being configured to use the existing binaries.

     

    99SBootStrapPluginsDomino6.ant

    Log file Recovery
    installDomino6Plugin.log

    1. If the error is due to plugin-cfg.xml not existing, investigate why this file is not present.

    2. If the error is due to the Web server definition creation failing, address this as discussed under the 98SConfigureWebserverDefinition.ant description.

    3. If the Web server configuration files do not update, investigate the files to verify that they exist and that the file permissions are correct.

    • Manually configure the Web server

    • Rerun the Plug-ins installation wizard. Select the existing plug-ins installation root directory. Doing so results in the Web server being configured to use the existing binaries.

     

    99SBootStrapPluginsDomino5.ant

    Log file Recovery
    installDomino5Plugin.log

    1. If the error is due to plugin-cfg.xml not existing, investigate why this file is not present.

    2. If the error is due to the Web server definition creation failing, address this as discussed under the 98SConfigureWebserverDefinition.ant description.

    3. If the Web server configuration files do not update, investigate the files to verify that they exist and that the file permissions are correct.

    • Manually configure the Web server

    • Rerun the Plug-ins installation wizard. Select the existing plug-ins installation root directory. Doing so results in the Web server being configured to use the existing binaries.

     

    99SBootStrapPluginsIIS6.ant

    Log file Recovery
    installIIS6Plugin.log

    1. If the error is due to plugin-cfg.xml not existing, investigate why this file is not present.

    2. If the error is due to the Web server definition creation failing, address this as discussed under the 98SConfigureWebserverDefinition.ant description.

    3. Start the Internet Information Services (IIS) application and investigate the IIS configuration.

    • Manually configure the Web server by

    • Rerun the Plug-ins installation wizard. Select the existing plug-ins installation root directory. Doing so results in the Web server being configured to use the existing binaries.

     

    99SBootStrapPluginsIIS5.ant

    Log file Recovery
    installIIS5Plugin.log

    1. If the error is due to plugin-cfg.xml not existing, investigate why this file is not present.

    2. If the error is due to the Web server definition creation failing, address this as discussed under the 98SConfigureWebserverDefinition.ant description.

    3. Start the IIS application and investigate the IIS configuration.

     

    99SBootStrapPluginsApache.ant

    Log file Recovery
    installApachePlugin.log

    1. If the error is due to plugin-cfg.xml not existing, investigate why this file is not present.

    2. If the error is due to the Web server definition creation failing, address this as discussed under the 98SConfigureWebserverDefinition.ant description.

    3. If the Web server configuration files do not update, investigate the files to verify that they exist and that the file permissions are correct.

    • Manually configure the Web server

    • Rerun the Plug-ins installation wizard. Select the existing plug-ins installation root directory. Doing so results in the Web server being configured to use the existing binaries.

     

    99SBootStrapPluginsIHS.ant

    Log file Recovery
    installIHSPlugin.log

    1. If the error is due to plugin-cfg.xml not existing, investigate why this file is not present.

    2. If the error is due to the Web server definition creation failing, address this as discussed under the 98SConfigureWebserverDefinition.ant description.

    3. If the Web server configuration files do not update, investigate the files to verify that they exist and that the file permissions are correct.

    • Manually configure the Web server

    • Rerun the Plug-ins installation wizard. Select the existing plug-ins installation root directory. Doing so results in the Web server being configured to use the existing binaries.

     

    99SGSKitInstall.ant

    Log file Recovery
    installGSKit.log

    1. In cases where the CD layout is not correct, then the gskit installer program cannot be found. GSKit fails to install.

    2. In cases where GSKit is already installed, the installation might incorrectly report a failure. If the logs show that an installation already existed, we can safely ignore the error.
    Manually install GSKit by running the installer program. The installGSKit.log file shows the installer program that runs to install GSKit. [AIX] [HP-UX] [Linux] [Solaris]

    Run the following command from the /cdrom/GSKit directory:

    /cdrom/GSKit/gskit.sh

    (Windows) Run the following command from the "E:\GSKit\ directory, assuming the E drive is the CD-ROM drive:

    • "E:\GSKit\Setup.exe" WASPLUGIN60_041008085014 "C:\Program Files" -s -z -f1"E:\GSKit\setup.iss"


     

    99SSolarisGSKitInstall4.ant (Solaris)

    Log file Recovery
    On Solaris, the installation is logged to the installGSKit.log file.

    1. In cases where the CD layout is not correct, then the gskit installer program cannot be found. GSKit fails to install.

    2. In cases where GSKit is already installed, the installation might incorrectly report a failure. If the logs show that an installation already existed, we can safely ignore the error.

    Manually install GSKit by running the installer program. [Solaris]

    Run the following command from the /cdrom/GSKit directory:

      /cdrom/GSKit/gskit4.sh


    (Windows)

    90SCreateWinRegPlugin.ant

    Log file Recovery

    Does not have an associated log file.

    The script creates the Windows registry entry for the Web server plug-ins for WAS.

    HKEY_LOCAL_MACHINE | Software | IBM | Web server Plug-ins for IBM WAS | 7.0.0.0

    Add the HKEY_LOCAL_MACHINE > Software > IBM > Web server Plug-ins for IBM WAS > 7.0.0.0 key manually with the actual value of the installation location.Set the following registry values under this key:

     

    99SModifySetupCmdLine.ant

    Log file Recovery

    Does not have an associated log file.

    Investigate the PLUGINS_ROOT/bin/setupCmdLine.sh script to verify that the PLUGIN_HOME variable is set to the Web server plug-ins installation root directory.

    Verify that file permissions are 755 (rwxr-xr-x) on systems such as AIX or Linux.

    • We can edit the setupCmdLine file, replacing $(PLUGIN_HOME) with the location to the plug-ins installation root directory.

    • Change the file permissions to 755. Issue the following command from the PLUGINS_ROOT/bin directory:

      chmod 755 setupCmdLine.sh
      

    If we do not find the cause of the problem, open the PLUGINS_ROOT/logs/web_server_name directory. The directory is empty until the Web server loads the plug-in and errors occur. The plug-in then creates the http_plugin.log file to record the errors. If no errors occur, the directory is empty. Examine any relevant files for error entries. Correct any errors and reinstall.

  • Does the installation result in a INSTCONFFAILED status?

    1. This is a serious failure of the installation.

    2. Analyze the log files to determine the problem.

    3. Uninstall the plug-ins.

    4. Delete the plug-ins installation root directory.

    5. Install the plug-ins again.

  • Do errors occur when you start the snoop application?

    See "Start the Snoop servlet" in the installation troubleshooting topic.

    If errors occur, look at the PLUGINS_ROOT/logs/web_server_name/http_plugin.log file for causes.

    Also investigate the WAS installation logs and the logs for the supported Web server.

  • [AIX] [HP-UX] [Linux] [Solaris]

    Do we have the correct file permissions for the configureWebServer script?

    On operating systems such as AIX or Linux, copying the configureWebServer.sh script from one operating system, such as AIX, to another, such as HP-UX, can cause the file permissions of the script to be invalid for running the script.

    Verify that file permissions are 755 (rwxr-xr-x) on systems such as AIX or Linux.

  • [AIX] [HP-UX] [Linux] [Solaris]

    Are you using the configureWebServer script when the Web server machine is running dynamic host configuration protocol (DHCP)?

    The configureweb_server_name.sh script can contain null values for the name of the host machine of the Web server when using DHCP. Examine the script to see if the last few parameters include the word null. If so, we have this problem.

    The plugins.install log file might also have an entry for the problem:

    (MMM DD, YYYY HH:MM:SS AM|PM), Plugin.Install, com.ibm.ws.install.ni.ismp.actions.ISMPLogFileAction, msg1, WEB_SERVER_HOSTNAME : null

    If WAS ND cannot resolve the host name of the server, problems can occur with such situations as adding or administering nodes, or the node agent contacting the appserver. To resolve the host name, WAS opens a port, or queries for an IP address. WAS ND v7.0 then waits for the operating system to return the correct information. The operating system might go to multiple places to find the IP address, but WAS does not care about the order in which the operating system does this, if the correct information is returned. If the host name of the server cannot be resolved, refer to the network administration documentation to resolve the problem.

    The following additional information might help you verify the host name is resolved.

    • Some operating systems create an association between the host name of the machine and the loopback address of 127.0.0.1. Red Hat installations create the association by default. The association is in the hosts file.

      If in the hosts file mappings exist from the 127.0.0.1 IP address to a host name other than localhost, remove the mappings.

      The following example illustrates what might happen if the mappings are not removed: When a node agent communicates with the dmgr, it sends its IP address to the deployment manager. The node agent resolves the node agent host name to 127.0.0.1 if the operating system returns a mapping for the host name from the hosts file. This resolution prevents the dmgr from sending a message to the node agent because the 127.0.0.1 IP address is also the IP address for the local machine of the dmgr.

      [AIX] [HP-UX] [Linux] [Solaris]

      The hosts file is located at /etc/hosts.

      (Windows) The hosts file is located at \WINDOWS\system32\drivers\etc\hosts.

    • [AIX] The default AIX installation checks the DNS first to return the information to a server so that the server host name of that server or another server can be resolved. If the host name cannot be resolved or cannot be resolved in a reasonable amount of time, we can add the following statement to...

      • /etc/netsvc.conf

      ...so that the AIX operating system checks the local hosts file first for the host name.

      hosts=local,bind

    Perform the following steps to successfully create the configuration script for creating and configuring the Web server definition in the appserver node:

    1. Uninstall the Web server plug-ins.

    2. Perform the suggested edits based on the operating system.

    3. Install the Web server plug-ins again.

     

    Troubleshooting plug-ins removal

    1. Does the PLUGINS_ROOT/logs/uninstall directory have any log files?

      If log files exist, examine them, correct the errors, and reinstall.

    2. Is there any sign that the removal occurred?

      If not, look for the temporaryPluginUnInstallLog.txt file in the temporary directory of the user who installed the plug-ins.

      For example, the /tmp/temporaryPluginUnInstallLog.txt file might exist if the root user uninstalled the plug-ins on a system such as AIX or Linux.

    3. Does the installation result in a INSTCONFPARTIALSUCCESS status?

      1. Look for errors in the log.txt file.

      2. Look for an entry in the log.txt file that shows the location of the masterConfigurationLog.txt file.

      3. Edit the masterConfigurationLog.txt file.

      4. Starting at the end of the file, scan towards the front of the file looking for configuration scripts that could not run. For example, the following stanza shows a configuration script that could not run:

        <record>
        <date>2004-10-08T10:31:43</date>
        <millis>1097245903200</millis>
        <sequence>189</sequence>
        <logger>com.ibm.ws.install.configmanager.ConfigManager</logger>
        <level>INFO</level>
        <class>com.ibm.ws.install.configmanager.ConfigManager</class>
        <method>dumpNonFatalFailedActionsInfoToLogFile</method>
        <thread>10</thread>
        <message>This action failed to execute:
          C:\Plugins\properties\version\install\plugin\7.0.0.0\
          config\full\uninstall\99SGSKitUnInstall.ant</message>
        </record>
        

      5. A script that fails to run is likely the cause of a partially successful installation status. To debug our example, look at the installGSKit.log, which is the log file for GSKit. Look for signs of a failed removal to determine if we can correct the problem.

       

      Configuration scripts and log files

      Configuration script Log file
      99SBootStrapPluginsSunOneUninstalluniqueID.ant
      99SBootStrapPluginsDomino6UninstalluniqueID.ant
      99SBootStrapPluginsDomino5UninstalluniqueID.ant
      99SBootStrapPluginsIIS6UninstalluniqueID.ant
      99SBootStrapPluginsIIS5UninstalluniqueID.ant
      99SBootStrapPluginsApacheUninstalluniqueID.ant
      99SBootStrapPluginsIHSUninstalluniqueID.ant

      uninstallWebServerPlugin.log

      For example, the file might be named:

      uninstallIHSPlugin.log

      Logs the Web server deconfiguration events for the Web server.

      99SGSKitUnInstall.ant uninstallGSKit.log

      On Windows only, the Web server plugins GSKit key will be unregistered. GSKit is uninstalled if no other product is registered to use GSKit.

      On operating systems such as AIX or Linux, it is the responsibility to uninstall GSKit when no other products are using it.

      90SDeleteWinRegPlugin.ant Does not have an associated log file.

      The script deletes the Windows registry entry for the Web server plug-ins for WAS.

      HKEY_LOCAL_MACHINE > Software > IBM > Web server Plug-ins for IBM WAS > 7.0.0.0

    4. Did the uninstall procedure fail?

      If the uninstall failed in any way, follow the manual uninstall steps to verify the system is clean and if necessary, remove Web server plug-in entries.

     

    Miscellaneous messages, tips and hints

    Description
    Unable to load mod_was_ap20_http... This error means that the following actions have occurred:

    • we have the 32-bit version of the Apache Web Server installed on a 64-bit platform.

    • You used the 64-bit platform CD to install the plug-in for the 32-bit Apache Web Server

    • You started the Apache Web Server and it could not load the 64-bit plug-in because it requires the 32-bit plug-in.

    To fix the problem, install the 32-bit plug-in from the CD for the 32-bit platform. Or manually configure the Apache Web server by changing httpd.conf to refer to the correct plug-in. Change the 64bit folder name in the directive to 32bit to fix the reference.

    For example, change...

      /IBM/WAS/Plugins/bin/64bit/mod_was_ap20_http.so

      ...to...

      /IBM/WAS/Plugins/bin/32bit/mod_was_ap20_http.so

      ...on a Linux system.

    SAFE_BROWSER_EXCEPTION_CAUGHT This SAFE_BROWSER_EXCEPTION_CAUGHT error means that:

    • If we do not have a browser, this error is thrown and the roadmap is not launched when it is selected during the installation of the plug-ins.

    • [AIX] [HP-UX] [Linux] [Solaris]

      If we have a supported browser not the Konqueror browser, the roadmap is launched. This message is thrown with the supported browser when it is not the Konqueror browser. We can safely ignore this exception and open the roadmap in a supported browser.

    number.tmp.sorted A limitation in ISMP does not remove temporary working files in the / root directory on Solaris operating systems. We can safely ignore or delete the files that follow this naming convention.

     

    Results

    This procedure results in troubleshooting the installation or removal of the Web server plug-ins for WAS.

     

    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 we need to resolve a problem. Before opening a PMR, see the IBM Support page.

     

    Related tasks

    Install Web server plug-ins