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.
- 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:
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.
- 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.
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,
- Refer to this article this 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
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
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
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:
- 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.
Log in or register to comment.