Troubleshooting user interface errors

When you encounter user interface errors in BMC Discovery, such as a login page failure, Home Page errors, or issues while performing a UI activity, use the troubleshooting steps described in this section to resolve the problem or create a BMC Support case.

Issue symptoms

UI error on the BMC Discovery login page, such as The appliance has been shut down.
UI unavailable, cannot connect, login, or access the Discovery UI because of these issues:
- connection reset
- page not found
- 500 error or the page is empty.
UI error when TKU upload fails.
UI fails while performing an interaction with errors like 500 - Internal Server Error.
Failure on any of the UI pages, such as Administration, Credentials, or Explore Data.

Issue scope

UI unavailable or cannot connect.
UI login with a user fails.
UI errors for a specific user or all users.
After a successful login, one or more pages or tabs of the UI fail.
UI fails while performing a specific activity, such as application modeling, backup and restore, or TKU upgrade.

Resolution

Perform the following steps to troubleshoot and resolve the user interface errors:

Step 1: Verify if the issue is consistent or transient

Perform the following steps to determine the consistency of the issue:

Check if the issue is always reproducible.
Check if the issue is reproduced on different browsers.
Reset the browser configuration to default and retry the UI action.
Check if the issue is experienced in a cluster environment. If it is then check if the issue is observed on all cluster machines or just some of the cluster machines.

Step 2: Verify if the issue is user-specific or consistent for all users

Perform the following steps to investigate the types of users affected:

Check if the issue is applicable for a specific UI user or all users. Also check the issue for a system user.
Log in to the BMC Discovery command line through a putty session using the tideway user and check if the problematic user is active. To do this use the command, tw_listusers.
Refer to this articlethis article on BMC Communities to further investigate and fix the user account lockout issue.

Step 3: Verify that all the Discovery application services are up and running

Perform the following steps to ensure that all the required services are running:

Log in to the BMC Discovery command line through a putty session using the tideway user.
Check if the all application services are in running state and no service is stopped with the following commands: (if it is on a cluster then verify the same on all the cluster machines).
- CentOS 6 or RHEL 6:
  sudo /sbin/service tideway status
  sudo /sbin/service cluster status
  sudo /sbin/service omniNames status
  sudo /sbin/service appliance status
- CentOS 7:
  tw_service_control --status
  sudo systemctl status cluster
  sudo systemctl status omniNames
  sudo systemctl status appliance
Check if the httpd service is in a running state using the following command:
sudo /sbin/service httpd status
If the service is stopped then start the service with the following command:
sudo /sbin/service httpd start
At times it may happen that not all services are up, even though running status shows the services are up. In such cases, run the start command to start the services.
Restart the application services with the following commands:
- CentOS 6 or RHEL 6:
  sudo /sbin/service tideway stop
  sudo /sbin/service cluster stop
  sudo /sbin/service omniNames stop
  sudo /sbin/service appliance stop
- CentOS 7:
  tw_service_control --stop
  sudo systemctl stop cluster
  sudo systemctl stop omniNames
  sudo systemctl stop appliance
In rare cases, a process may be "stuck" and not end cleanly. To check for this, run the command:
ps –ef | grep python
Then kill any remaining python processes:
kill -9 <pid>
Note that there are two "privileged" processes owned by root, for example:
root 7490 1 0 May21 ? 00:00:00 python /usr/tideway/python/privileged/main.pyc --daemon start
root 7495 7490 0 May21 ? 01:02:43 python /usr/tideway/python/privileged/main.pyc --daemon start
It is not necessary to kill these, however doing so will cause no harm.

CentOS 6 or RHEL 6:
sudo /sbin/service appliance start
sudo /sbin/service omniNames start
sudo /sbin/service cluster start
sudo /sbin/service tideway start
CentOS 7:
sudo systemctl start appliance
sudo systemctl start omniNames
sudo systemctl start cluster
tw_service_control --start

Step 4: Verify if appliance is running out of disk space

Perform the following steps to verify if the appliance is running out of disk space:

Log in to the Discovery command line through a putty session using the tideway user.
Check if the appliance has appropriate available resources and if the partition is running out of space with the command: df -h
If you notice that a disk partition is full (space issue) then refer to this article to investigate and fix this issue,

Step 5: Identify if the issue is reproduced only while executing specific steps

Perform the following steps:

Narrow down the use case if this is a specific issue reproduced while performing a specific activity, such as TKU upload, application modelling, Query/reporting, upgrade, or backup and restore.
Check if there was a recent activity performed on this environment after which the issue was noticed. Note down the activity, such as OS upgrade, TKU upgrade, or Discovery appliance upgrade. This may have triggered the issue so should be helpful when investigating the issue.

If the problem persists, collect the model and reasoning, user interface, and system message logs in debug mode while reproducing the issue.

Collect the logs using the steps described in the topic, Collecting-additional-data-for-support-cases. You can review the logs and identify the error messages. You can also contact Customer Support and provide the results to all the questions/checks you performed earlier.