Oracle EBS Concurrent Manager Will Not Start: How to Fix It
Oracle EBS concurrent manager not starting
Also searched as
- 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
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.
Applies to: EBS 11i, 12.1.3, and 12.2.x (Concurrent Processing tier)
How to restart a stuck concurrent manager
- 1In the System Administrator responsibility go to Concurrent > Manager > Administer and check which managers show Deactivated, Not Running, or a target/actual mismatch.
- 2Open the Internal Concurrent Manager log under $APPLCSF/$APPLLOG for the actual startup error.
- 3Verify 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.
- 4If 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.
- 5From the OS, check for stale FNDLIBR, FNDSM, or FNDCPESR processes still running: ps -ef | grep FND - kill orphaned processes before restarting.
- 6Confirm 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.
- 7Restart 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.
- 8If 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.
The FND_NODES / hostname mismatch after cloning
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
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
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.
Common 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.
How an ERP-grounded AI assistant handles this
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.
Frequently asked questions
Why does the Internal Manager fail right after cloning an EBS environment?
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?
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?
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?
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.
Related
Fix FRM-40735: WHEN-VALIDATE-RECORD Trigger Raised Unhandled Exception ORA-06508
FRM-40735 with ORA-06508 almost always means a PL/SQL package used by the form was recompiled while your session still held the old cached state, or the trigger's own exception handling does not trap a real data error. Exit the form completely and re-enter it; if the error repeats for all users, recompile invalid objects on the database and check for a bad custom trigger.
Error fixFix Oracle EBS Workflow Notification Mailer Not Sending Emails
When EBS notifications stop reaching inboxes, check the mailer status in Oracle Applications Manager (OAM) Workflow Manager first - a Suspended or Error status almost always points at an SMTP or IMAP connectivity or credential problem introduced by a mail server change, not at Workflow itself. Fix the mail server configuration, restart the mailer component, and requeue the backlog.
Error fixFix ORA-01555: Snapshot Too Old in Oracle EBS Concurrent Requests
ORA-01555 in a concurrent request means the program tried to read data from undo that has already been overwritten, usually because the report or custom PL/SQL ran long enough, or committed often enough mid-cursor, that the undo tablespace could not retain the needed read-consistent image. Increase UNDO_RETENTION and undo tablespace size first, then review the program for commits inside open cursor loops.
Error fixFix adop phase=prepare Failures in EBS 12.2 Online Patching
An adop prepare phase failure in EBS 12.2 almost always means the patch edition (patch file system) and the run edition are out of sync, or a previous cutover or cleanup did not complete cleanly. Read adop.log for the specific worker error, resync the file systems with adop phase=fs_clone if needed, and never start a new patch cycle on top of an unfinished one.
How-toHow to Import AP Invoices in Oracle EBS with Payables Open Interface Import
Load invoice header and line data into AP_INVOICES_INTERFACE and AP_INVOICE_LINES_INTERFACE, then run the Payables Open Interface Import concurrent program to create standard invoices in Oracle Payables. Rows that fail validation land in AP_INTERFACE_REJECTIONS with a specific reject reason you can query directly, without opening the Invoice Workbench.
How-toHow to Use Forms Personalization in Oracle EBS (No CUSTOM.pll Needed)
Forms Personalization lets you change field properties, set defaults, run built-ins and show messages on any Oracle Forms screen through Help > Diagnostics > Custom Code > Personalize, with no custom library or forms compile required. Rules are stored per form and responsibility in FND_FORM_CUSTOM_RULES and apply at runtime for every user who opens that form.
AI for ERPAI for Oracle E-Business Suite, Without Leaving On-Prem
Add AI to Oracle E-Business Suite 12.2 without moving off-prem. Query concurrent programs, interface tables, and AP/PO data with a private LLM. See how.
AI for ERPAI Agents for ERP, Running On-Prem
A practical guide to on-prem AI agents for ERP: what they can safely automate, where human approval belongs, and how to design the guardrails.
Stuck on Oracle E-Business Suite (EBS)?
Talk to engineers who work inside Oracle E-Business Suite (EBS) every week, and who build private AI that answers these questions from your own ERP data.