InfoCenter Home >
8: Problem determination >
8.5: Problem determination quick reference >
8.5.3: Installation problems
8.5.3: Installation problems
Successful installation means that no errors occur during the installation process and,
more importantly, that the product runs correctly the first time you start it.
Installation and startup problems occur for one of the following reasons:
Install options
WebSphere Application Server provides a Java graphical installation
that is available on all platforms, and a native installation that is available on the
UNIX platforms.
Note: If you used the native install option to install
WebSphere Application Server on a UNIX platform, you must also uninstall
using the native uninstall option. In other words, you cannot do a native
install and use the graphical interface to uninstall.
Follow the steps in one of the case-specific installation documents to
install the product.
Database configuration problems
If the database is not configured properly, installation
of WebSphere Application Server will fail. If specific WebSphere components did install but the
database is misconfigured, the product will not run properly.
Starting WebSphere Application Server with an improperly
configured database will generate the following error messages and exceptions:
Establishing connection please wait ... Error - could not get attributes
com.ibm.ejs.util.cache.FaultException at java.lang.Throwable<init>
com.ibm.ejs.sm.client.ClientException getAttributeFailure Attributes may be involved
com.ibm.ejs.sm.client.RpositoryOpException could not get attributes
Classpath problems
The classpath provides the Java runtime environment for the
following WebSphere Application Server processes:
- Administrative service - the backend process for system management
- Administrative console - the graphical interface used for system management
- One or more application servers - each application server consists of
multiple containers for deployment of enterprise beans and one Web container for deployment of Web applications
- Nanny service (on UNIX platforms only) - a daemon that monitors
the administrative service. The nanny service starts the administrative service
initially and restarts it if it fails.
Each of these processes runs in its own Java Virtual Machine (JVM). The classpath for each process tells
that process where to search for classes. The classpath can be set:
- In an administrative service startup script
- In an admin.config file
- With application server command line arguments
- By Web applications
Classpath properties
Each process has an associated set of properties ("Java-speak" for environment variables).
These properties are defined in the admin.config file that is located in directory:
product_installation_root/bin
The applicable properties in admin.config file are:
- com.ibm.ejs.sm.adminserver.classpath
The classpath settings in the admin.config file apply to the administrative
service, and they are also inherited by all other WebSphere Application Server processes.
For more information on these and other WebSphere Application Server properties, see file,
6: Administer applications.
Classpath failures
Typical classpath failures are:
- When a servlet class is missing from a Web application classpath, the following errors occur:
- In a browser window, the browser displays error Error 500 with message,
"Failed to load target servlet [snoop]."
- Browser stack trace and <AppServerName>_stderr.log show
java.lang.ClassNotFoundException
- <AppServerName>_stdout.log shows
javax.servlet.ServletException
- When utility classes, such as dates.class or time.class, are in
a Web application's classpath, the following errors occur:
- Browser shows error message
java.lang.VerifyError
- Verbose JVM output written to the <AppServerName>_stderr.log shows
java.lang.VerifyError: com/bcs/jsftest/test
Note: A WebSphere Application Server problem exists on
the Windows NT platform which prevents the stderr buffer from being flushed until the application
server is stopped. No circumvention for this problem is available at this time.
- When classes use Java Native Interface (JNI), the following errors occur:
- <AppServerName>_stdout.log shows
java.lang.UnsatisfiedLinkError
To resolve the problem, do the following:
- Ensure the shared libraries are available in the path statement on Windows NT.
On UNIX, make sure the LD_LIBRARY_PATH is defined in file startupServer.sh.
- Ensure that the property defined in com.ibm.ejs.sm.adminserver.classpath, in the admin.config
file, includes classes that make JNI calls into shared libraries.
- Ensure that directories containing native modules accessed by JNI calls are on the
com.ibm.ejs.sm.util.process.Nanny.path
property in admin.config
Administrative server problems
Successfully starting the administrative server not only indicates a successful install of WebSphere Application
Server, but it also means the following tasks were completed:
- System management repository tables were created in the database.
- A node object and host aliases were defined in the repository.
Therefore, when the administrative server fails to start, it also means the installation of WebSphere
Application Server is incomplete.
Administrative server start failures
The administrative server fails to start for the following reasons:
- The port is in use. See the port problems section for more information.
- Another administrative server is running. See the InfoCenter article 6.6a: Starting the product for more information.
- The WebSphere Application Server database repository, (was on DB2 or
ORCL on Oracle), is not created. The first time you start the administrative server process, it
attempts to create the default configuration in the was or ORCL
database. You will see a Specific error 10 message if the database is not created.
- Connection to DB2 or Oracle fails. You need to ensure that DB2 is running and that the connection
to the was database is successful.
To test the DB2 connection, from a DB2 command window, type:
DB2 connect to was
If you cannot connect to DB2, verify the following:
- Ensure the right level of code is installed on the WebSphere Application Server machine
- For a remote repository, ensure the DB2 client is configured properly to
point to DB2 server for the was database.
- Ensure the database manager has been started
Perform the same tests for Oracle. - User ID does not have proper authority or access:
- To ensure proper authority, follow the database configuration steps in the install guides.
- In the UNIX environment, log on as root to start AdminServer.
- In the Windows NT environment, verify the following conditions are true:
- User is logged in as an administrative user
- User name in security panel is correct
- User is part of the administrator's group.
- The Administrative server is registered as a service to Windows NT. To manually add the administrative server as a service, from a command prompt, enter:
product_installation_root\bin\adminservice.exe
install product_installation_root\bin\admin.config <HostName>\<User> <Password>
- User ID has proper rights to start the administrative server. If using a domain ID, start the administrative server with a local ID to see if the domain is the problem. To check a user's rights:
- From Start > Programs > Administrative Tools > User Manager
- Select Policies > User Rights
- Check Show Advanced User Rights checkbox in lower left corner
- Add the following rights to the user ID:
- Log on as a service
- Act as part of the operating system
- If you change the Windows NT user ID/password but WebSphere Application Server is
not updated, then the administrative server startup will fail.
Update the user ID/password in the following areas:
- In Windows NT services for the IBM WebSphere Administrative Server service:
- From Start > Settings > Control Panel, double click Services
- Select IBM WebSphere Administrative Server
- Click Startup
- Change the user ID/password under this account
- in admin.config (if the DB2 userid/password also changed)
Port problems
WebSphere Application Server will fail to start if certain ports are in use. Typical port problem descriptions follow:
- When the bootstrap port is in use,
you may see the following error when starting WebSphere:
009.765.6005c5b F Nameserver Failed to start the Bootstrap server
org.omg.CORBA.INTERNAL: minor code: 8 completed: No
This error is similar to the Port 9000 in use error when starting WebSphere Application Server.
To fix the problem, change the bootstrap port (the default is 900) in file, admin.config,
using property name:
com.ibm.ejs.sm.adminServer.bootstrapPort
If this property does not exist in file admin.config, add it.
- Port 9000 is the default port of the Admin Server location service daemon.
Port 9000 is also used by many system resources including AIX X-windows manager.
If you see error message,
Port 9000 in use-select another port
when executing the ./startupServer.sh command on AIX,
the administrative server process cannot start because port 9000 is in use.
You can change the port the location service daemon listens on by:
- specifying -lsdPort option on the admin server command line
- setting com.ibm.ejs.sm.adminServer.lsdPort property in the
admin.config file
|
|