cancel
Showing results for 
Search instead for 
Did you mean: 

IdM Dispatcher: RELOAD Thread didn't start, exiting ...

Former Member
0 Kudos

Hello,

I am experiencing an issue with IdM dispatcher on Linux. The DB is DB2. The dispatcher was working fine, and is modeled after other working dispatchers; however, the dispatcher will no longer start. I have attached the debug log.

Any help is appreciated.

Thanks,

Michael

Here is the end of the attached log (showing the error message):

[23.11.2015 19:21:27-360] - 101 - UNORDERED   - Execution starts

[23.11.2015 19:21:27-361] - 101 - UNORDERED   - Executing clear old semas

[23.11.2015 19:21:27-372] - 101 - UNORDERED   - Started execution of 'listSuitableTasks'

[23.11.2015 19:21:27-372] - 101 - STATEMENT PREPARED: SELECT   * FROM MXPV_GROUPTASKS_UNORDERED

[23.11.2015 19:21:27-374] - 101 - UNORDERED   - No unordered groups found, nothing to do

[23.11.2015 19:21:27-374] - 101 - UNORDERED   - Nr. of unordered groups:0

[23.11.2015 19:21:27-378] - 101 - Thread:IDS_DispThread_UNORDERED  _<server_name> - Sleeping:2

[23.11.2015 19:21:27-466] - 101 - Waiting for successful start-up of the thread:CFG_RELOAD

[23.11.2015 19:21:27-687] - 101 - JOBEXECUTE  - Execution starts

[23.11.2015 19:21:27-688] - 101 - JOBEXECUTE  - Runtime count mode (0=process):0

[23.11.2015 19:21:27-688] - 101 - STATEMENT PREPARED: SELECT count(jobid) as COUNT from mc_jobs where state = 2

[23.11.2015 19:21:27-690] - 101 - STATEMENT PREPARED: SELECT count(jobid) as COUNT from mc_jobs where state = 2 and current_machine = ? PARAMETERS: <server_name>

[23.11.2015 19:21:27-692] - 101 - JOBEXECUTE  - This dispatcher has started: 0 runtimes

[23.11.2015 19:21:27-692] - 101 - JOBEXECUTE  - Started execution of 'getWaitingjobs'

[23.11.2015 19:21:27-699] - 101 - JOBEXECUTE  - No action tasks found - nothing to do

[23.11.2015 19:21:27-699] - 101 - JOBEXECUTE  - Nr. of executions:0

[23.11.2015 19:21:27-699] - 101 - Thread:IDS_DispThread_JOBEXECUTE _<server_name> - Sleeping:5

[23.11.2015 19:21:28-217] - 101 - EVAL_APPR.  - Execution starts

[23.11.2015 19:21:28-218] - 101 - EVAL_APPR.  - Executing clear old semas

[23.11.2015 19:21:29-344] - 101 - ORDERED     - Execution starts

[23.11.2015 19:21:29-344] - 101 - ORDERED     - Executing clear old semas

[23.11.2015 19:21:29-379] - 101 - UNORDERED   - Execution starts

[23.11.2015 19:21:29-379] - 101 - UNORDERED   - Executing clear old semas

RELOAD Thread didn't start, exiting ...

[23.11.2015 19:21:29-467] - 101 - RELOAD Thread didn't start, exiting ...

[1]    Done                          ./Dispatcher_Service_<server_name>dev.sh

Accepted Solutions (0)

Answers (1)

Answers (1)

former_member2987
Active Contributor
0 Kudos

Hmmm.... so 7.2 on Linux.  And it looks like you are using Java 6....

This information looks somewhat troubling... can you confirm? Not even sure how to troubleshoot this reliably and for a production environment.  (I have some ideas but they are kinda out there )


STOP_DISPATCHER field in the mc_dispatcher table for dispatcher '<server_name>' has value 0 ...

This indicates that dispatcher '<server_name>'

    - has been previously stopped abruptly

    - or other dispatcher with same name is already running

So next things I would start to consider....

Have the rights for the user running the dispatcher been changed? I believe they should have read, write, and execute.  I would confirm the configuration against this document, , It's still valid for LINUX and 7.2.

Have you checked database permissions for the MXMC* accounts? I think in DB2, they are actually IC* accounts or something like that.

You might not have changed something, but that doesn't mean that a DBA, BASIS, or System Admin did not.

Are other dispatchers working? Compare the .SH and the .PROP files.  If you could please post the .SH and .PROP files to the dispatcher.  I think most of the sensitive stuff is encrypted, but you might want to sanitize just to be safe.

Matt

Former Member
0 Kudos

Yes, 7.2 on Linux utilizing Java 6. Is this not a valid configuration? It is working for other IdM SIDs in the landscape at the moment. Thanks for the response. The issue appears to be with a third party tool that is new in the landscape called Centrify. The vendor has been notified.

Thanks,

Michael

former_member2987
Active Contributor
0 Kudos

Hi Michael,

Sure Java 6 will work, but it has been my experience that as the product evolves it's best to use a later version of Java.  Note that there are some documented issues with Java 8 which I *think* are resolved with the latest service packs.

How did Centrify interfere?

Matt

Former Member
0 Kudos

Hi Matt,

It may not be a Centrify issue. The issue is now occurring on other application servers. Do you happen to know if there are any parameters to control the time that it will wait for CFG_RELOAD thread(s) to complete?

-Michael

former_member2987
Active Contributor
0 Kudos

Hi Michael,

No, I don't.  You might need to open a support note.

Matt

Former Member
0 Kudos

Thanks for the feedback. I've opened a new incident with SAP.

-Michael