If a server process does not start or starts with errors,
the following topics might help you to diagnose the problem.
Installation program completes successfully, but an
application server does not start, or starts with errors
Note: This topic references one or more of the application
server log files. As a recommended alternative, you can configure
the server to use the High Performance Extensible Logging (HPEL) log
and trace infrastructure instead of using SystemOut.log , SystemErr.log, trace.log, and activity.log files on distributed and IBM® i systems. You can also use
HPEL in conjunction with your native z/OS® logging facilities. If you are using HPEL, you can access
all of your log and trace information using the LogViewer command-line
tool from your server profile bin directory. See the information
about using HPEL to troubleshoot applications for more information
on using HPEL.
- Browse the Application
Server log files for clues. The log files are located by default
in:
![[Linux]](../images/linux.gif)
profile_root/logs/server_name/SystemErr.log and SystemOut.log
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]](../images/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.
For example, 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.
- After you create an application server, you must synchronize the
nodes before saving the configuration settings for the new server.
If you do not synchronize the nodes, your new server might not start.
- On the Applications server page listing all of your application
server, click Preferences.
- Select Synchronize changes with Nodes, if it is not already
selected.
- Click Apply and then click Application servers to
return to your list of application servers.
- Click Save to save the configuration settings for the new
server.
- 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.
Before starting an application server, use
the startNode Qshell script to start the node agent process on the
nodes hosting the application servers you are starting.
- 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 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 Apache Derby and receive an ERROR XSDB6:
Another instance of Apache Derby might have already booted the database databaseName error when starting the application
server, consult the topic Data access problems 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.
When using a user profile other than QEJBSVR
to run an application server, verify that:
- The application server might not start in the restricted mode.
You can configure an application server to allow or restrict access
to internal server classes. The default is to allow access. If access
is restricted, the server might not start. If the application server
does not start in Restrict mode, change the access to internal
classes to Allow.
An error message might appear in the SystemOut.log
after 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: netstat -a
Verify that no ports are listening. Use this
CL command: NETSTAT *CNN
- Restart the server
Message "DiscoveryService.sendQuery" exception appears
in the FFDC log file
When you start a deployment manager,
the deployment manager attempts to discover any configured node agents
within its cell. If the deployment agent does not discover the node
agents in the cell, it writes an exception to the first failure data
capture (FFDC) log file for each node agents that the deployment manager
does not discover. If the node agents are not suppose to be running,
you can ignore the exception. If the node agents are suppose to be
running, the FFDC log file might contain additional information that
will help you determine why the deployment manager cannot discover
the node agents even though the node agents are suppose to be running.
![[IBM i]](../images/iseries.gif)
The server
does not restart on IBM i after
applying WebSphere Application
Server Version 8.5.0.1
If the server does not restart on IBM i after applying 8.5.0.1, you
might receive the following message: "CWWKE0044E: There is
no write permission for server directory."
This error
occurs only on IBM i when started
with OS integration and using the QEJBSVR user.
You can temporarily
resolve this by wrapping an invocation of the server command with
a script that deletes the contents of the <serverName>/workarea/.sCommandAuth directory.
IBM Support
has documents and tools that can save you time gathering information
needed to resolve problems. Before opening a problem report, see the
Support page: