View on GitHub

Appendix H
Troubleshooting

H.1 Introduction

This appendix explains how to troubleshoot and resolve omniNames/omniEvents failures.

H.2 Performing a Hard Reset Using the cleanomni Script

The cleanomni script is used to perform a hard reset of omniNames and omniEvents and delete the associated log files. To run this script, enter the following command:

The cleanomni script performs the following commands:

H.3 Diagnosing Problems Using the rh_net_diag Script

The rh_net_diag script is a Python script used to diagnose various omniORB-related problems and to perform other system checks to diagnose potential problems that may impact a REDHAWK installation. To run this script, enter the following command:

By default, the --ns (Naming Service), --dom (Domain Manager), and --dev (Device Manager) options are enabled when the script is executed. These options assume that omniNames, the Domain Manager, and the Device Manager are all running on the host executing the script. For help with rh_net_diag, enable the -h option. For more detailed output, enable the -v option. The four test categories include:

H.4 Performing a Soft Reset of omniNames and omniEvents

If the runtime-error indicates a Naming Service failure, enter the following command to attempt a soft reset on omniNames:

This process first performs a stop and then performs a start. If the stop process fails, omniNames was never started, stopped due to an error condition, or is in a non-recoverable state. If the start process fails, omniNames is either misconfigured or already running (i.e., omniNames was not stopped).

omniNames can potentially report a successful start and then fail soon after. If the omniNames service appears to fail after reporting a successful start, a reconfiguration and hard reset of omniNames may be necessary. For more information, refer to Section H.6 and Section H.2.

A restart of omniEvents may be necessary when restarting omniNames. To perform a soft reset of omniEvents, enter the following command:

H.5 Setting Omni Log Levels

When diagnosing omniNames/omniEvents problems, it is often useful to set the omni logging levels. Use the following procedure to set the omni logging levels (requires root permissions):

  1. Open the /etc/omniORB.cfg file.
  2. Set a traceLevel value. For example:

Details on the available trace levels can be found in Chapter 4 of the omniORB User’s Guide (http://omniorb.sourceforge.net/omni41/omniORB/omniORB004.html or on your local system at file:///usr/share/doc/omniORB-devel-4.1.6/doc/omniORB/omniORB004.html).

For the changes to take effect, restart omniNames/omniEvents.

Log messages are displayed in the terminal and in the files contained in /var/log/omniORB and /var/lib/omniEvents.

H.6 Common Causes for omniNames Failure

H.6.1 IP Version 6 Conflicts

Certain combinations of IP Version 6 (IPv6) configurations and /etc/omniORB.cfg configurations can cause omniNames failures.

Specifically, if the InitRef section of /etc/omniORB.cfg is set to point to localhost rather than pointing explicitly to 127.0.0.1, the operating system may resolve localhost to ::1 (the IPv6 localhost) and not to 127.0.0.1 (the IPv4 localhost). If this occurs, omniNames fails. There are three options for preventing this failure condition:

H.6.1.1 Preventing IPv6 localhost Resolution

Below is an example /etc/hosts file from an older CentOS distribution:

Below is an example /etc/hosts file from a newer CentOS distribution:

In the older /etc/hosts file, localhost resolves unambiguously to 127.0.0.1. In the newer /etc/hosts file, localhost can resolve to either 127.0.0.1 or ::1 (where resolving to ::1 causes an omniNames failure).

The newer /etc/hosts file can be modified to read:

Alternatively, localhost4 can be used in the InitRef section of /etc/omniORB.cfg.

The line pertaining to IPv6 can also be completely removed from the file; however, some operating systems, depending on IPv6 configurations, may automatically repopulate IPv6 localhost settings on reboot.

H.6.2 Invalid IP Addresses in /etc/hosts

Invalid entries in the /etc/hosts file may induce an omniNames failure. Invalid entries may be in the form of an IP address that cannot be reached or in the form of an entry that is not valid according to the /etc/hosts grammar.

Firewall IP and Port settings on both the server and client side may cause the target omniNames service to be unreachable.


Creative Commons License
REDHAWK Documentation is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.