Troubleshooting guide for RPM

In the event of an OpenIAM installation failure, users can troubleshoot and identify potential issues by collecting and examining logs. Below is a general guide on how to collect logs for failed installations and individual service failures, which is the first step in troubleshooting.

Collecting OpenIAM installation logs

If the OpenIAM installation fails, retrieve the init.log file from the following directory.

cd /usr/local/openiam
[root@rhel9 openiam]# ls -lrth | grep init
-rw-r--r--.  1 root    root    222K Jan 29 13:54 init.log

Collecting logs for individual failed services

To collect logs for individual services, navigate to the logs directory and list the available log files.

cd /usr/local/openiam/logs
[root@rhel9 logs]# ls -lrth

Example log files are the following.

-rwxrwxrwx. 1 root    root       0 Jan 29 13:49 vault.out
-rw-r--r--. 1 openiam openiam  41K Feb  2 10:19 business-rule-manager.log
-rw-r--r--. 1 openiam openiam  41K Feb  2 10:19 reconciliation.log
-rw-r--r--. 1 openiam openiam  41K Feb  2 10:19 synchronization.log
-rw-r--r--. 1 openiam openiam  41K Feb  2 10:19 groovy-manager.log
-rw-r--r--. 1 openiam openiam  53K Feb  2 10:19 workflow.log
-rw-r--r--. 1 openiam openiam  43K Feb  2 10:19 device-manager.log
-rw-r--r--. 1 openiam openiam  86K Feb  2 10:21 idm.log
-rw-r--r--. 1 openiam openiam  61K Feb  2 10:21 email-manager.log
-rw-r--r--. 1 openiam openiam  61K Feb  2 10:21 auth-manager.log
-rw-r--r--. 1 openiam openiam 168K Feb  2 10:51 openiam-esb.log

Collecting OpenIAM UI logs

To retrieve catalina.out log for the OpenIAM UI, navigate to the following directory.

cd /usr/local/openiam/ui/logs

To list Catalina logs use the following.

[root@rhel9 logs]# ls -lrth | grep catalina
-rw-r-----. 1 openiam openiam 927K Jan 29 18:50 catalina.2025-01-29.log
-rw-r-----. 1 openiam openiam 309K Jan 30 05:56 catalina.2025-01-30.log
-rw-r-----. 1 openiam openiam 1.8M Feb  2 10:23 catalina.out
-rw-r-----. 1 openiam openiam 272K Feb  2 10:23 catalina.2025-02-02.log

OpenIAM CLI commands for individual service logs

To check logs for specific services, use the following OpenIAM CLI commands.

openiam-cli log openiam-esb
openiam-cli log idm
openiam-cli log openiam-ui
openiam-cli log workflow
openiam-cli log auth-manager
openiam-cli log device-manager
openiam-cli log reconciliation
openiam-cli log synchronization
openiam-cli log groovy-manager
openiam-cli log email-manager

Checking Journalctl logs for individual services

To check service logs using journalctl, use the following commands.

journalctl -u openiam-esb
journalctl -u idm
journalctl -u openiam-ui
journalctl -u workflow
journalctl -u auth-manager
journalctl -u device-manager
journalctl -u reconciliation
journalctl -u synchronization
journalctl -u groovy-manager
journalctl -u email-manager

Writing and Sharing Live-Log Files

When troubleshooting, it’s usually best to capture and share only the logs that are directly related to the issue. Instead of sending the full application log (which can be very large and include unrelated information), you can create a new file that contains only the events from the moment you reproduce the problem.

Steps on Linux

1. Open a terminal.
2. Run the following command to start writing the live logs into a temporary file, for example for ESB logs:

tail -f /usr/local/openiam/logs/openiam-esb.log > /tmp/esb_live_issue.txt

tail -f continuously reads the end of the main log file and saves everything into a new file under /tmp.

3. While this command is running, go back to the application and perform the action that causes the problem.

4. Once the error happens, stop the command by pressing Ctrl + C.

5. Now you’ll find the captured log file at:

/tmp/esb_live_issue.txt 6. Share this file with us.

Why this helps

By following this process, the file you share will only contain logs generated during the failed action, rather than the entire application history. This makes the investigation quicker and avoids sending unnecessary data.

Which file shell I send to OpenIAM support?

• openiam-esb.log – This is the main service bus log, and it’s almost always useful. Please include this file with your report regardless of the issue.
• idm.log – Use this when the problem is related to provisioning, identity management operations, or user account changes.
• email-manager.log – Share this when the issue involves email delivery (e.g., notifications not being received).
• synchronization.log – Relevant if the issue happens during a synchronization process.
• reconciliation.log – Needed when reconciliation tasks fail or produce unexpected results.
• business-rule-manager.log – Share this (together with idm.log) if you observe that business rules are not being applied correctly.
• auth-manager.log – Useful when a user cannot see menus, is missing access to certain screens they should have, or during provisioning troubleshooting where access rights are involved.
• device-manager.log – Share if problems occur in device-related operations.
• groovy-manager.log – Usually not helpful for troubleshooting. Please do not send this log by default; we will request it only if needed.
• workflow.log – Provide this when you experience issues with submitting or approving requests, user access certification, or completing review actions — essentially, anything related to workflows initiated from the self-service portal.
• ldap-connector-rabbitmq.log – Share this only if the issue is related to provisioning or synchronization through the LDAP connector (if your system is configured to use it).

General Guidance

Always include openiam-esb.log along with the specific log file related to your operation.

If you’re unsure which log file to share, just consider which kind of operation you performed and which OpenIAM service that operation corresponds to — use common sense to pick the relevant log. For more complex issues (e.g., involving workflows, business rules, or provisioning), it may be necessary to include two or more logs together.

Do not send unnecessary logs (like groovy-manager.log,device-manager.log) unless specifically requested, as they rarely provide useful information.

By choosing the right log file, you help us quickly identify what went wrong and speed up the resolution process.