Use this topic to diagnose possible problems when the installation
is unsuccessful. The installer program records the following indicators of
success at the end of the primary log file, which can be found in
install_root/logs/wbi/log.txt on
Linux and UNIX platforms or
install_root\logs\wbi\log.txt on
Windows platforms:
- INSTCONFSUCCESS: installation was successful
- INSTCONFPARTIALSUCCESS: installation was partly successful.
Some installation actions failed but can be retried.
- INSTCONFFAILED: installation was not successful. Recovery
is not possible.
If the result is
INSTCONFPARTIALSUCCESS or
INSTCONFFAILED,
continue analyzing the problem by following these steps:
- If the installation process displayed any error messages, check Error messages: installation, profile creation and augmentation for an explanation.
If the message corresponds to any of those described, correct the
problem, clean up any installed portions, and try to reinstall.
For
details about uninstalling any portions that are still installed, before reinstalling,
refer to Preparing for reinstallation after a failed uninstallation.
- Determine if the installation of WebSphere Application Server Network Deployment was
successful. If the installation of WebSphere ESB was
not successful, first check install_root/logs/log.txt on
Linux and UNIX platforms or install_root\logs\log.txt on
Windows platforms for errors to determine if the installation of WebSphere Application Server Network Deployment was
successful.
- If the installation of WebSphere Application Server Network Deployment failed,
review the troubleshooting
installation information for WebSphere Application Server Network Deployment.
Use the information found there to correct the problems before attempting
to reinstall WebSphere ESB.
- If the installation of WebSphere Application Server Network Deployment succeeded
and the installation of WebSphere ESB failed,
use the troubleshooting information below to correct the problems.
- Check the WebSphere ESB installation
log files for errors after installing.
Refer to Log files for the names, locations, and descriptions
of the various log files that are created. Check the log files in this sequence:
On Linux and UNIX platforms:- install_root/logs/wbi
- %tmp% if no files are found in install_root/logs/wbi
- install_root/logs/wasprofile/wasprofile_create_ profile_name.log or install_root/logs/wasprofile/wasprofile_augment_ profile_name.log.
If you performed a Complete installation, which creates a stand-alone server
named default, the value for profile_name will
be default.
- Any additional log or trace files generated by installation actions. Look
in install_root/logs/wbi for trace files
generated during the installation (or uninstallation) process. Look in profile_root/logs for
those generated by profile creation or augmentation, where profile_root represents
the installation location of the WebSphere ESB profile
(by default, install_root/profiles/profile_name on
Linux and UNIX platforms). These files are primarily intended for use by IBM
technical support.
On Windows platforms:- install_root\logs\wbi
- %tmp% if no files are found in install_root\logs\wbi
- install_root\logs\wasprofile\wasprofile_create_ profile_name.log or install_root\logs\wasprofile\wasprofile_augment_ profile_name.log.
If you performed a Complete installation, which creates a stand-alone server
named default, the value for profile_name will
be default.
- Any additional log files generated by installation actions. Look in install_root\logs\wbi for
trace files generated during the installation (or uninstallation) process.
Look in profile_root\logs for those generated
by profile creation or augmentation, where profile_root represents
the installation location of the WebSphere ESB profile
(by default, install_root\profiles\profile_name on
Windows platforms). These files are primarily intended for use by IBM technical
support.
- If there is no information in the installation logs, use the -log parameter
with a response file.
Certain events can prevent the InstallShield
for Multiplatforms (ISMP) 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 with a response file to record entries
for events that cause the ISMP program to fail to start the Installation Wizard.
This will work with any one of the following response files:
- responsefile.esb.txt
- responsefile.pcaw.esb.standAloneProfile.txt
- responsefile.pcaw.esb.dmgrProfile.txt
- responsefile.pcaw.esb.managedProfile.txt
For more information about response files, refer to Installing WebSphere ESB silently.
You will need to copy a response
file from WebSphere ESB CD
1 to your system’s hard drive to use it. The syntax of the install command
for logging such events is as in the following examples (your paths to the
response file and the log file, and the actual name of the response file might
differ):
On AIX platforms: install -options "/usr/IBM/WebSphere/silentFiles/myresponsefile.txt"
-silent -log # !/usr/IBM/WebSphere/myOptionFiles/log.txt @ALL
On HP-UX, Linux, and
Solaris platforms: install -options "/opt/IBM/WebSphere/silentFiles/myresponsefile.txt"
-silent -log # !/opt/IBM/WebSphere/myOptionFiles/log.txt @ALL
On Windows platforms: install.exe -options "C:\IBM\WebSphere\silentFiles\myresponsefile.txt"
-silent -log # !C:\IBM\WebSphere\silentFiles\log.txt @ALL
- Determine whether the installation problem is caused by a configuration
script that failed.
The install_root/logs/wbi/instconfig.log file
on Linux and UNIX platforms or install_root\logs\wbi\instconfig.log file
on Windows platforms indicates configuration problems that can prevent the
product from working correctly. Search on the string action failed to
find the name of the configuration script that failed.
- Verify that no files exist in the install_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 install_root/classes directory.
By
default, the install_root/classes directory
is picked up first in the WebSphere ESB 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 should 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.
- Uninstall the product, clean up any log files or other artifacts
that are left behind, 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:
- 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:
- If you have successfully created a server profile, use the First
steps console or the command line method to start the server.
Start
the First steps console for a particular node (where
profile_root represents
the installation location of the
WebSphere ESB profile
(by default,
install_root/profiles/profile_name on
Linux and UNIX platforms and
install_root\profiles\profile_name on
Windows platforms):
On Linux and UNIX platforms: profile_root/firststeps/esb/firststeps.sh
On Windows platforms: profile_root\firststeps\esb\firststeps.bat
Start the server from the command line:- Change directories to the profile_root/bin directory
in the profile.
- Start the server process.
On Linux and UNIX platforms: ./startServer.sh server_name
On Windows platforms: startServer.bat server_name
- Verify that 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 directories:
On Linux and UNIX platforms: profile_root/logs/server_name
On Windows platforms: profile_root\profiles\logs\server_name
- Use the First steps console or the command line method to stop
the server server_name, if it is running, and to start
the deployment manager if one exists.
To start the deployment manager from
the command line:
On Linux and UNIX platforms: profile_root/bin/startManager.sh
On Windows platforms: profile_root\bin\startManager.bat
- 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.
On Linux and UNIX platforms: 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 system, use the
ps command:
ps -ef | grep java
On Windows platforms: 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.
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.
For current information available from IBM Support on known problems
and their resolution, see the IBM WebSphere ESB support page.