If the WebSphere Application Server installation program completes
successfully, but the Application Server does not start, or starts with errors
- Browse the Application
Server log files for clues. The log files are located by default in:
![[Linux]](../../linux.gif)
install_root\ profiles\ profile_name\
logs\ server_name\ SystemErr.log and SystemOut.log
install_root/ profiles/ profile_name/
logs/ server_name/ SystemErr.log and SystemOut.log
Several applications deployed on an Application Server or node can take
time to start. Browse the SystemOut.log periodically
and look at the most recent updates to see if the server is still starting
up.
![[Linux]](../../linux.gif)
The tail -f install_root/
profiles/ profile_name/ logs/ server_name/
SystemOut.log is a convenient way to watch the progress of the
server.
- Look for any errors or warnings relating to specific resources with the
module, such as Web modules, enterprise beans and messaging resources. If
you find any, examine the Application Server configuration file for the configuration
settings of that resource. For example, in a base or non-distributed configuration
on Windows systems, browse install_root/ profiles/ profile_name/
config/ cells/ ApplicationServerCell/ nodes/ node_name/
servers/ server_name/server.xml, and examine
the XML tags for the properties of that resource. Change its initialState value
from START to STOP. Then restart the
server to see if this component causes the problem.
- Look up any error or warning messages in the message reference table by
clicking the Reference view of the information center navigation and
expanding Messages in the navigation tree.
- If the Application Server is part of a network deployment
or multiple server configuration,
- Verify that you followed the
steps for adding the Application
Server to the configuration.
- Verify that the configuration is synchronized between the deployment manager
and the node. If auto synchronization is running, wait until the synchronization
completes. If you are using manual synchronization, request a synchronization
to each node in the cluster.
- Before starting an Application Server:
- Start the deployment manager process by issuing the following command:
![[Linux]](../../linux.gif)
install_root/bin/startManager.sh
install_root\bin\startManager.bat
- Complete the one-time step of federating the node on which the Application
Server is running to the deployment manager. This step has to be done, even
if there is only one node. And even if both processes are on the same physical
server. Verify that the deployment manager is running.
Then run the
addNode nodename command
from the
install_root/profiles/App_Server_profile/bin directory.
For example, the following command adds the Application Server to the deployment
manager on a Linux or UNIX system:
addNode.sh localhost 8879 -includeapps -startingport 3333
The
deployment manager is using the default SOAP port of 8879. Both processes
are on the same machine. All of the installed applications (except the administrative
console, which is a system application) on the Application Server are installed
on the deployment manager.
The startingport parameter avoids a problem
with coexisting node agent processes on one machine. All of the ports for
the node agent process start at port number 3333. You can also assign ports
specifically using the -portprops parameter.
See the description of
the addNode command for
more information.
- Start the node manager process on the nodes hosting the Application Servers
you want to run by typing either install_root/bin/startNode.sh or install_root\bin\startNode.bat.
- Verify that the logical name that you specified to appear
on the console for your Application Server does not contain invalid characters
like: - / \ : * ? " < > and leading or trailing spaces.
- If you are unable to start the deployment manager after
an otherwise successful installation, look in the install_root/
profiles/ profile_name/ logs/ server_name/
SystemErr.log file and the SystemOut.log file
for messages.
- If you are using IBM Cloudscape and receive an ERROR XSDB6: Another
instance of Cloudscape may have already booted the database databaseName error
when starting the Application Server, consult
this topic for more information.
- When using a non-root user ID to run Application Servers, verify that:
- The non-root user has write access to the install_root/temp directory.
- The JVM has write access to install_root/config/plugin-cfg.xml file.
- The non-root user has access to the logs directory.
Message "The socket bind failed for host hostname and
port portnumber. The port may already be in use." occurs when restarting
an Application Server.
The following error message might appear
in the SystemOut.log after restarting the Application Server:
The socket bind failed for host hostname and port portnumber. The port may already be in use.
This
problem might occur if the network is slow, and the port listed in the message
text did not finish listening when the application was stopped and restarted.
To
verify that this is the problem, check the port status.
To correct this
problem, wait for a few minutes after stopping the server:
- Verify that no ports are listening. Use the command: 'netstat
-a .
- Restart the server
If you do not
see a problem that resembles yours, or if the information provided does not
solve your problem, seeObtaining help from IBM.