Why and when to perform this task
If you did not receive the Successful installation message or the INSTFIN: The installation is complete. line in the installation log, use this information to troubleshoot the installation.
Steps for this task
The deployment manager process (dmgr) in the Network Deployment product manages a cell of Application Servers. You can federate a base Application Server into the cell or unfederate it. While federated, the configuration of the base Application Server is managed from the deployment manager.
Installing creates the /logs/log.txt file
and the /logs/WAS.PME.install.log file. Uninstalling creates the install_root/logs/uninstlog.txt file
and the install_root/logs/WAS.PME.uninst.log file.
Tip for viewing Install Shield Multiplatforms (ISMP)
generated log files on Linux and UNIX-based platforms Version 5.1 installation
logs generated by ISMP 5.0.1 might have incorrect line-end characters. If
you cannot use the vi command to view a log file successfully, view
the file in a viewer such as more.
The following table shows
the installation log locations when installing the application clients for
Version 5.1. The location is fixed and might not agree with the installation
root location if you specified a location during installation.
Windows system log path name | Linux and UNIX-based operating system log path name |
---|---|
C:\Program Files\WebSphere\AppClient\logs\ WAS.Client.install.log | /opt/WebSphere/AppClient/logs/ WAS.Client.install.log |
Component | Installation log path name | |
---|---|---|
Windows platforms: install_root\logs\ | Linux and UNIX-based operating system platforms: install_root/logs/pme/ | |
WebSphere Application Server Enterprise | log.txt uninstlog.txt PMEinstallSummary.log WAS.PME.install.log |
|
Administrative console | installAdminConsole.log | |
Component | Windows platforms: install_root\logs\pme\ | Linux and UNIX-based operating system platforms: install_root/logs/pme/ |
WebSphere Application Server Enterprise | PluginProcessorInst.log PMEinstallApps.log |
This directory lets you verify or debug a fix. After accepting the test fix or finishing with the debugging of the debug fix, you are supposed to 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.
install.bat -is:javaconsoleor capture the stream to a file with the following commands:
install.bat -is:javaconsole > drive:\captureFileName.txt
install.bat -W Setup.product.install.logAllEvents="true"
If you install on an AIX 5.1 system, with maintenance level 2, it is possible that the Web-based system manager, a standard component of AIX systems, already uses port 9090. When starting the server you get information that port 9090 is already in use. To resolve the conflicting port use, change the port assignment for the HTTP_TRANSPORT_ADMIN port in the server.xml file. The file path is:
usr/websphere/appserver/config/cells /cell/nodes/node/servers/server1/server.xml
To start the deployment manager from the command line:
In a Network Deployment environment, the Snoop servlet is available in the cell only if you included the DefaultApplication when adding the Application Server to the cell. The -includeapps option for the addNode command migrates the DefaultApplication to the cell. If the application is not present, skip this step.
To start the IBM HTTP Server from the command line: Access the apache and apachectl commands in the IBMHttpServer/bin directory.
The server starts. The administrative console starts. You can access the administrative console through the browser. The administrative console accepts your login.
Begin federation of node xxxx with deployment manager at localhost:8879. Successfully connected to deployment manager Server: localhost:8879 Creating node agent configuration for node: xxxx Reading configuration for node agent process: nodeagent Adding node xxxx configuration to cell: AdvancedDeploymentCell Performing configuration synchronization between node and cell. Launching node agent process for node: xxxx Node agent launched. Waiting for initialization status. Node agent initialization completed successfully. Process ID is: 3012 Node xxxx has been successfully federated.
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 0 specifies to never cache.
Using a zero 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 SDK, Standard Edition 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 SDK, Standard Edition 1.4. The Networking section of the Java 2 SDK, Standard
Edition 1.4 Web site at
http://java.sun.com/j2se/1.4.1/jcp/beta/
describes
a change in the behavior of the java.net.URLConnection class.
If you are installing from an operator console attached to the RHEL 3 U1 machine and you receive a message that is similar to the following message, you might be experiencing a known limitation of RHEL 3 U1:
A suitable JVM could not be found
Red Hat Enterprise Linux 3.0 causes a segmentation fault when calling the JVM. The problem occurs when you run the installation program, log off of the root user, log back on to root, and run the installation again on the operator console that is attached to the machine (not a telnet session).
The installation fails with a segmentation fault.
This is a known limitation of Red Hat Enterprise Linux V3.0 that causes a segmentation fault when calling the JVM.
Test the JVM to see if it is failing by running the following command:
/mnt/cdrom/platform/linuxi386/jdk/java/jre/bin/java -version
If you receive a "segmentation fault" message, reboot your machine or press Ctrl-x to reinstall. Rebooting the machine or pressing Ctrl-x resolves the problem.
a file is bad no such file or directory exists libCSup.2 cannot be accessed
The copy error occur when incorrectly copying symbolic link files.
An example of such an error occurs when copying an HP-UX CD image onto an AIX platform with the cp -frp command. The default cp command behavior on AIX is to resolve the symbolic links by copying the files to which the symbolic links point. Errors occur when a symbolic link resolves to a platform-specific library or file that is not present on the NFS operating system.
Use options on the copy command of the NFS system to copy symbolic links instead of resolving them. For example, the -h option on the cp command of the AIX platform copies symbolic links from the HP-UX CD to the NFS disk on the AIX platform.
Even with the -h option, the cp command on a Solaris platform does not preserve symbolic links when copying an HP-UX disk. On a Solaris platform, use the tar -cvf command to copy data from an HP-UX disk and preserve the symbolic links:
CD /cdrom/cdrom0
tar cvf * /workarea/filename.tar
CD /workarea
tar -xvf filename.tar
Consult the man page for the copy command on the NFS system to understand how the platform supports copying symbolic links.
On many systems, such as SuSe Linux, if you telnet and issue the id command or the groups command, you cannot see the groups mqm or mqbrkrs even though they might exist. Solve this problem in one of two ways:
In a normal root login, issue the su command. For a real root login, issue the su - command.
Display settings for a normal root login are automatic. For a real root login, you must set your display environment properly to successfully view the GUI installation wizard. Otherwise, you see a message about Preparing Java(tm) Virtual Machine... and seven rows of dots, but no installation GUI and no further messages. Refer to the documentation for your platform to determine proper display settings.
If you see the following messages in the SystemOut.log file, you have not picked up the required secondary groups for root:
[date time CDT] 60cf2faf JMSRegistrati A MSGS0601I: WebSphere Embedded Messaging has not been installed [date time CDT] 60cf2faf JMSEmbeddedPr A MSGS0050I: Starting the Queue Manager [date time CDT] 60cf2faf JMSEmbeddedPr E MSGS0058E: Unable to start the JMS Server as WebSphere Embedded Messaging has not been installed [date time CDT] 60cf2faf JMSService E MSGS0001E: Starting the JMS Server failed with exception: java.lang.Exception: MSGS0058E: Unable to start the JMS Server as WebSphere Embedded Messaging has not been installed
Also, the following associated messages are added to the mq_install.log file:
wmsetup: date time Checking if user "root" is in group "mqm" wmsetup: date time wmsetup: date time ERROR: Group "mqm" exists, id "root" is defined to the group but does not wmsetup: date time have the group in its current set of effective groups. wmsetup: date time Current group membership is : wmsetup: date time uid=0(root) gid=0(system) groups=2(bin) wmsetup: date time You may need to login. wmsetup: date time wmsetup: date time ... RC 4 from Check_root wmsetup: date time ERROR: User "root" not in group "mqm" wmsetup: date time Check_root mqbrkrs wmsetup: date time Checking for group "mqbrkrs" ... wmsetup: date time lsgroup returned "mqbrkrs id=203 admin=false users=root adms=root registry=files " RC=0 wmsetup: date time Checking if user "root" is in group "mqbrkrs" wmsetup: date time wmsetup: date time ERROR: Group "mqbrkrs" exists, id "root" is defined to the group but does not wmsetup: date time have the group in its current set of effective groups. wmsetup: date time Current group membership is : wmsetup: date time uid=0(root) gid=0(system) groups=2(bin) wmsetup: date time You may need to login. wmsetup: date time wmsetup: date time ... RC 4 from Check_root wmsetup: date time ERROR: User "root" not in group "mqbrkrs"
java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:41) at java.lang.reflect.Method.invoke(Method.java:386) at com.ibm.ws.bootstrap.WSLauncher.main(WSLauncher.java:94)Caused by: java.lang.NumberFormatException: For input string: "" at java.lang.NumberFormatException.forInputString(NumberFormatException.java:62) at java.lang.Integer.parseInt(Integer.java:469) at java.lang.Integer.parseInt(Integer.java:498) at com.ibm.websphere.ivt.client.ivtClient.main(Unknown Source) ...
When starting the Launchpad program for WebSphere Application Server clients, Version 5.1 using the Konqueror file manager in the K Desktop Environment (KDE) on Linux systems, a "Couldn't find the program launchpad.sh" error occurs.
Because the launchpad.sh command uses a relative path to locate the Java program, you should run the launchpad.sh command from the directory where the launchpad.sh command is located for the client program. When using the Konqueror file manager to issue the launchpad.sh command, the current directory is your home directory. Therefore, the launchpad.sh command cannot work.
Results
You can troubleshoot the installation.What to do next
The troubleshooting section of the information center, as described in Troubleshooting or problem determination, 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 IBM Support at thehttp://www.ibm.com/support/search.wss?rs=180&tc=SSEQTP&tc1=SSCVS24 IBM Web address.
IBM Support has documents that can save you time gathering information needed to resolve this problem. Before opening a PMR, see the IBM Support page .