# Oracle EBS Concurrent Manager Will Not Start: How to Fix It > Source: https://netray.co/erp-help/ebs-concurrent-manager-not-starting-fix > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## Short answer A concurrent manager that will not start in Oracle EBS is almost always one of three things: the node registered in FND_NODES no longer matches the actual hostname (common after cloning), stale OS processes are blocking a fresh start, or the database and listener the manager connects to are unreachable. Check the internal manager log, verify the node name, clear stale processes, and restart with adcmctl.sh. ## Kind error ## System oracle-ebs ## Erp Oracle E-Business Suite (EBS) ## Module System Administration / Concurrent Processing ## Query Oracle EBS concurrent manager not starting ## Alternate Queries - Internal Concurrent Manager will not start after clone - EBS concurrent manager status shows deactivated - FNDLIBR process not starting EBS - concurrent manager stuck not running after reboot ## Applies To EBS 11i, 12.1.3, and 12.2.x (Concurrent Processing tier) ## Steps ### How to restart a stuck concurrent manager **Items:** - In the System Administrator responsibility go to Concurrent > Manager > Administer and check which managers show Deactivated, Not Running, or a target/actual mismatch. - Open the Internal Concurrent Manager log under $APPLCSF/$APPLLOG for the actual startup error. - Verify the node name: Install > Node in System Administration must match the current hostname exactly, especially after a clone - a mismatch is the single most common cause after adclone. - If the environment was recently cloned or renamed, rerun AutoConfig (adautocfg.sh) on both the database and apps tiers so FND_NODES and the context file agree. - From the OS, check for stale FNDLIBR, FNDSM, or FNDCPESR processes still running: ps -ef | grep FND - kill orphaned processes before restarting. - Confirm the database is reachable and the listener is up: a TNS-12541 or ORA-12154 in the manager log points at a listener or tnsnames problem, not the manager itself. - Restart Concurrent Processing cleanly with adcmctl.sh stop apps/pwd followed by adcmctl.sh start apps/pwd, or adstpall.sh/adstrtal.sh for the whole apps tier. - If managers still show Running in the form but nothing is actually running, use the Administer screen to Deactivate then Activate rather than editing FND_CONCURRENT_PROCESSES status directly. ## Sections ### The FND_NODES / hostname mismatch after cloning **Body:** The most frequent cause of a manager that simply refuses to come up after a clone, a server rename, or even a straightforward IP change is a stale entry in FND_NODES - the Internal Manager's target-node logic, enforced through Generic Service Management, will flatly refuse to start a manager whose configured node does not match what the server itself reports as its hostname. This check exists to stop a manager starting against the wrong tier after a botched clone. AutoConfig is the safe way to fix this: rerunning adautocfg.sh on both the database tier and every application tier node regenerates the context file and the FND_NODES entries consistently across the whole environment in one pass. Manually editing FND_NODES directly in SQL is technically possible but easy to get wrong, especially in a multi-node install, and it is not the Oracle-documented approach for recovering from a clone. ### Stale OS processes blocking a clean start **Body:** If a server crashed, was killed with kill -9, or the apps tier was shut down uncleanly, orphaned FNDLIBR or FNDSM processes can remain in the process table while EBS believes the manager is stopped, or vice versa. Starting a new manager instance in that state either fails silently or spawns a second set of processes that fight over the same request table rows. Always check ps -ef | grep FND on every concurrent processing node before restarting anything, and cross-check the output against FND_CONCURRENT_PROCESSES rows still marked Running that no longer have a matching OS process behind them. Those orphaned rows should be terminated cleanly through the Administer screen's Terminate option, not deleted directly in SQL, since a raw delete can leave the queue control tables in an inconsistent state. ### Database and listener reachability **Body:** Concurrent managers are background processes connecting to the database like any other session; if the listener is down, TNS is misconfigured, or the database is unreachable from the apps tier, the manager log shows ORA-12154 or TNS-12541 rather than an application-level error. Fix the connectivity first, confirming with tnsping or a simple sqlplus connection test from the apps tier - the concurrent manager problem resolves itself on its own once the database is reachable again. This is also the pattern to expect after a database server was patched, moved to new hardware, or had its listener port changed without the apps tier's tnsnames.ora and context file being updated to match the new details. Check both files first whenever a TNS or connectivity error shows up alongside a manager that will not start, before assuming the concurrent manager configuration itself is at fault. ## Pitfalls - Restarting the manager repeatedly without checking the log first - the internal manager log almost always states the real reason on the first failed attempt. - Forgetting to rerun AutoConfig on both tiers after a clone - fixing only the database tier context file leaves a mismatch. - Killing FNDLIBR processes with kill -9 instead of a clean adcmctl.sh stop, which creates more orphaned rows in FND_CONCURRENT_PROCESSES. - Editing FND_NODES manually instead of through AutoConfig, which can leave the table inconsistent with the context file. - Assuming the manager itself is broken when the real problem is the database listener or a network or firewall change. ## Ai Angle ERPray grounded on the EBS admin tables (FND_NODES, FND_CONCURRENT_PROCESSES, FND_CONCURRENT_QUEUES) can read the actual internal manager log alongside those tables and tell a support engineer in plain language whether the block is a node mismatch, an orphaned OS process, or an unreachable database - instead of the usual trial-and-error of stopping and starting the manager a few times and hoping. ## Faq ### Why does the Internal Manager fail right after cloning an EBS environment? **Answer:** Cloning changes the server's hostname, but FND_NODES and the context file on the cloned instance often still reference the source environment's original node name until AutoConfig is rerun. Rerunning AutoConfig on both the database and application tiers after the clone realigns everything automatically; this is a documented, expected step in the standard cloning procedure, not a defect. ### How do I know if a stuck manager is a stale OS process problem? **Answer:** Compare the output of ps -ef | grep FND on the server directly against the process list shown in Concurrent > Manager > Administer inside the application. If FND_CONCURRENT_PROCESSES shows rows still marked Running with no matching OS process behind them anywhere on the server, those rows are orphaned and need to be terminated cleanly through the Administer screen. ### What is the fastest first check when a manager will not start? **Answer:** Open the Internal Concurrent Manager log file under $APPLCSF/$APPLLOG immediately, before trying anything else. The first line of a failed start attempt almost always states the real reason plainly - a node mismatch, a TNS connection error, or an OS-level permissions problem - which is far faster than guessing and restarting repeatedly. ### Can a full log filesystem stop concurrent managers from starting? **Answer:** Yes - if $APPLCSF/$APPLLOG, or the underlying operating system filesystem hosting it, fills up completely, managers can fail to write their startup log and fail to start at all, often with a confusing or truncated error. Check disk space on the concurrent processing tier as a quick early check before digging into node or database configuration. ## Search terms EBS concurrent manager not starting, Internal Concurrent Manager down, FNDLIBR not starting, concurrent manager deactivated EBS, FND_NODES mismatch clone, adcmctl.sh restart concurrent manager, AutoConfig concurrent manager fix, EBS concurrent processing not running, internal manager log concurrent manager error, concurrent manager stuck after reboot --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json