TL;DR
- What this covers: Bringing IBM WebSphere Application Server (WAS) Network Deployment back up cleanly after the host has been rebooted.
- Order matters: Deployment Manager → Nodeagent on each node → Application Servers. Skipping the order is the most common cause of “agent not synchronised” errors.
- Where you do the work: SSH into the host as
root(or a WAS-owning user) and run the shell scripts in$WAS_HOME/profiles/<profile>/bin. The console at:9043/ibm/consoleis for the final app-server start. - Sanity-check first: If the box was hard-rebooted, check
SystemOut.logfor in-flight transactions and a clean stop before bringing services back up.
New to TurboGeek? This is one of a series of practical guides for sysadmins. If you work with Linux servers daily, the Linux Start Here hub collects every guide on the site by topic.
| Phase | Script | Run from |
|---|---|---|
| 1. Deployment Manager | ./startManager.sh | $WAS_HOME/profiles/Dmgr01/bin |
| 2. Nodeagent (each node) | ./startNode.sh | $WAS_HOME/profiles/AppSrv01/bin |
| 3. Application Servers | ./startServer.sh <name> or WAS console | $WAS_HOME/profiles/AppSrv01/bin |
What is WebSphere?
WebSphere Application Server in a Network Deployment topology is not a single process —it’s a small constellation. There’s a Deployment Manager (Dmgr) that owns configuration and admin, a Nodeagent on each managed node that synchronizes that configuration locally and supervises the application server JVMs, and the application servers themselves, where your apps actually run. After a host reboot, none of these come back automatically unless you’ve explicitly wrapped them in systemd units or rc scripts. Most installs don’t. So you bring them up by hand, in order.
The order is not optional. The Dmgr must be up before the nodeagents register; the nodeagents must be up before the Dmgr can issue start commands to the application servers. If you start an application server while the nodeagent is down, you get a JVM that’s running but invisible to the admin console, which is worse than not running, because monitoring will believe everything is fine.
Prerequisites
- SSH access to every node (Dmgr host plus each managed node) as a user who owns
$WAS_HOME— typicallyrooton RHEL installs, or a dedicatedwasadminOS user. - WAS admin console credentials (default username
wasadmin) — needed only if you start the application servers from the console rather than the command line. - Console URL — typically
https://<deployment-manager-host>:9043/ibm/console/logon.jsp. Port 9043 is the default secure admin port; checkserverindex.xmlif your install differs. - Profile path — paths in this guide assume the IBM defaults:
/opt/IBM/WebSphere/AppServer/profiles/Dmgr01and.../profiles/AppSrv01. If your install was customized, runfind /opt -name startManager.shto locate yours.
Step 1: Start the Deployment Manager
The Deployment Manager is the central administrative process for your cell. It hosts the admin console, owns the master configuration repository, and is the only thing that can issue cluster-wide commands. Nothing else will register until it’s up.
SSH into the Dmgr host as root (or your WAS-owning user) and run:
cd /opt/IBM/WebSphere/AppServer/profiles/Dmgr01/bin
./startManager.shExpect the script to run for 30–90 seconds and finish with ADMU3000I: Server dmgr open for e-business; process id is <PID>. If you see ADMU0509I: The Application Server "dmgr" cannot be reached followed by a stack trace, jump to Troubleshooting below.
Step 2: Start the Nodeagent on the First Node
The nodeagent is the local supervisor on each managed node. It synchronises configuration from the Dmgr, starts and stops the application server JVMs on that node, and is what the admin console actually talks to when you click “Start” on a server. SSH into the first managed node and run:
cd /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/bin/
./startNode.shLook for ADMU3000I: Server nodeagent open for e-business; process id is <PID>. The nodeagent will immediately initiate a configuration sync with the Dmgr — a few seconds of network chatter is normal.
Step 3: Start the Nodeagent on the Second Node
Repeat on every other managed node in the cell. Two-node clusters are the most common topology, but you may have three or more — the script and the path are identical, the host is what changes:
cd /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/bin/
./startNode.shConfirm both (or all) node agents show as Started on the admin console under System administration → Node agents before moving on. If one is greyed out, the Dmgr has not yet seen it — usually a transient sync issue, give it 30 seconds.
Step 4: Start the Application Servers
With the Dmgr and all node agents up, you can finally start the application server JVMs. Either approach works — the command line is faster for scripting; the console is friendlier if you have many servers and want a visual confirmation of cluster state.
Option A: Command line
cd /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/bin/
./startServer.sh server_name_you_want_to_startRun this on the node that hosts the server. Replace server_name_you_want_to_start with the actual server name (e.g. server1, AppServerA, etc.). Look for ADMU3000I: Server <name> open for e-business.
Option B: WAS admin console
- Browse to
https://<dmgr-host>:9043/ibm/console/logon.jspand sign in. - Navigate to Servers → Server Types → WebSphere application servers.
- Tick the checkbox next to each server you need to start.
- Click Start. Wait for the status icons to turn green; the console will show “Started” once the JVM is fully up. A delayed-start configuration may take 2–5 minutes per server.
Order recap: Deployment Manager first, then every nodeagent, then the application servers. Reverse the order to shut down: app servers, then nodeagents, then Dmgr.
Verification
Once everything is started, sanity-check from the command line. Each server’s serverStatus.sh will report STARTED if the JVM is healthy:
# On the Dmgr host
cd /opt/IBM/WebSphere/AppServer/profiles/Dmgr01/bin
./serverStatus.sh dmgr
# On each managed node
cd /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/bin
./serverStatus.sh nodeagent
./serverStatus.sh -allBrowser-side: log into the console, go to System administration → Cell. Every node and server should show as Started. The cell topology view is the fastest visual check for partial failures — anything still amber needs another look.
Application-side: hit your application’s health endpoint (or any known URL) through the front-end load balancer. A 200 response confirms the request path is whole — DNS, web tier, plug-in, app server. If you have one app server up but the load balancer is still 503-ing, check that the IHS plug-in config has refreshed.
Troubleshooting
“Address already in use” on Dmgr or nodeagent start
A previous JVM didn’t shut down cleanly and is still holding the port. ps -ef | grep java on the host; kill any stale WebSphere PIDs; remove $WAS_HOME/profiles/<profile>/logs/<server>/<server>.pid if present, then retry.
Nodeagent shows “unavailable” in the console
The Dmgr can’t reach the node. Check (a) the nodeagent is actually started on the node — ./serverStatus.sh nodeagent — and (b) the SOAP and ORB ports between Dmgr and node are open in the firewall. The default SOAP port is 8878, ORB 9101. ss -tlnp | grep -E '8878|9101' on the node should show them listening.
Profile path differs from the defaults in this guide
Custom installs may use Custom01, node1, nd-profile, or names ending in environment suffixes (-prod, -uat). Find your actual paths with find /opt -maxdepth 6 -name startManager.sh -o -name startNode.sh 2>/dev/null.
SSL handshake error logging into the console
WAS rotates a self-signed default cert that browsers will refuse. Either accept the cert exception in the browser or replace the default DummyServerKeyFile.jks entry on the Dmgr’s secure admin endpoint. For production, use a CA-signed cert via Security → SSL certificate and key management.
The application server starts, but the app is unavailable
The JVM is up, but the application failed to deploy. Tail $WAS_HOME/profiles/AppSrv01/logs/<server>/SystemOut.log — look for WSVR0017E (Application failed to start) or class-loader errors. Most reboot-related deployment failures trace back to a missing data source: a database that hasn’t come back up yet, or a JNDI lookup that times out before the DB is reachable.
Related reading
- Linux Start Here — every Linux guide on the site, organised by topic.
- Linux SSH hardening checklist — SSH is the entry point for all WAS administration; lock it down properly.
- Ubuntu Server: first 30 minutes checklist — adapts cleanly to any RHEL/Debian server you’ll be running WAS on.
Leave a Reply