Installation program completes successfully, but an 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)
profile_root\logs\server_name\SystemErr.log and SystemOut.log
profile_root/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 profile_root/
logs/server_name/SystemOut.log command 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. Then restart the server to see if this component
causes the problem.
For example, in a base or non-distributed
configuration on Windows systems, browse profile_root/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.
- 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 added
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:
- 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
profile_root/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 app_server_root/bin/startNode.sh or app_server_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 profile_root/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 app_server_root/temp directory.
- The JVM has write access to app_server_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 an 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: .
- Verify that no ports are listening. Use this CL command:
NETSTAT *CNN
- Restart the server
For current information available from IBM Support on known
problems and their resolution, see the IBM Support page. You should also refer to this page
before opening a PMR because it contains documents that can save you time
gathering information needed to resolve a problem.
If you do not see a problem that resembles yours, or if
the information provided does not solve your problem, seeTroubleshooting help from IBM.