This topic describes troubleshooting the installation of the WebSphere Application Server - Express product.
If you are looking for troubleshooting information for WebSphere Application Server products on iSeries platforms, see iSeries installation troubleshooting tips. This topic does not describe i5/OS 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.
Use this topic to help interpret the log files and diagnose possible problems when the installation is unsuccessful.
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.
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. 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 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.
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 disc.
Log files for 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
Windows system log path name | Operating system log path name on systems such as AIX or Linux |
---|---|
Log | Content | Indicators |
---|---|---|
app_server_root /logs/install/log.txt | Logs all installation events |
|
user_data_root/profileRegistry/logs/manageprofiles/create.log |
|
|
app_server_root/logs/install/ installconfig.log |
|
|
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.
<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 Management tool and the manageprofiles command create the log when creating an application server profile:
Log files for Web server plug-ins for WebSphere Application Server
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 systems such as AIX or Linux.
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.
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.
Test your environment by starting your Application Server, your Web server, and using the snoop servlet with an IP address.
Use either the 2001 page or use the STRTCPSVR SERVER(*HTTP) HTTPSVR(instance_name ) command to start the IBM HTTP Server.
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.
Either Web address should display the Snoop Servlet - Request/Client Information page.
"Could not connect to IHS Administration server error"
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.
The server starts. The administrative console starts. You can access the administrative console through the browser. The administrative console accepts your login.
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
The Java 2 Platform Standard Edition (J2SE) 1.4.2 Web site and the Java 2 Platform Standard Edition (J2SE) 1.5 Web site describe the private sun.net.inetaddr.ttl property, which works in both J2SE 1.4.2 (WebSphere Application Server Version 5.1 and Version 6.0) and J2SE 1.5 (WebSphere Application Server Version 6.1).
This procedure results in debugging errors that might occur during 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.
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. Most of the following links will take you to information that is not part of the formal product documentation and is provided "as is." Some of these links go to non-IBM Web sites and are provided for your convenience only and do not in any manner serve as an endorsement by IBM of those Web sites, the material thereon, or the owner thereof. |