0

I am attempting to install REDHAWK v1.8.2 on a fresh install of CentOS 6.4 32 bit, but I am unable to get omniNames and omniEvents to start. 

sudo /sbin/service omniEvents stop
Stopping CORBA event service: omniEvents

sudo /sbin/service omniNames stop
Stopping omniNames                                         [  OK  ]

sudo /sbin/service omniNames start
Starting omniNames                                         [  OK  ]

sudo /sbin/service omniEvents start

Starting CORBA event service on port 11169: omniEvents: [25848]: Warning - failed to resolve initial reference 'NameService'. Exception: TRANSIENT
omniEvents.

I tried to verify if omniNames was really running by calling the naming client, but got an error (see below), so it seems omniNames is not successfully starting.

nameclt list
Caught a TRANSIENT exception when trying to validate the type of the 
NamingContext. Is the naming service running?

As part of the debugging process, I tried to kill the omniNames process and start it a different way (see below).

sudo killall omniNames
omniNames -start

Wed Nov 13 21:08:08 2013:

Starting omniNames for the first time.
Error: cannot create initial log file '/var/omninames/omninames-orion.log': 
No such file or directory

You can set the environment variable OMNINAMES_LOGDIR to specify the
directory where the log files are kept.

I'm not sure why omniNames can't create the log file, because I verified that /var/omninames folder actually exists and even starting omniNames as root yields the same error. Regardless, I set the log directory to my desktop to circumvent the error (see below).

export OMNINAMES_LOGDIR=/home/$USER/Desktop/logs
mkdir -p /home/$USER/Desktop/logs
omniNames -start

Wed Nov 13 21:09:17 2013:

Starting omniNames for the first time.
Wrote initial log file.
Read log file successfully.
Root context is IOR:010000002b00000049444c3a6f6d672e6f72672f436f734e616d696e672f4e616d696e67436f6e746578744578743a312e30000001000000000000005c000000010102000a00000031302e322e382e333500f90a0b0000004e616d6553657276696365000200000000000000080000000100000000545441010000001c00000001000000010001000100000001000105090101000100000009010100
Checkpointing Phase 1: Prepare.
Checkpointing Phase 2: Commit.
Checkpointing completed.

Even though it looks like omniNames successfully started, when I open another terminal window and call the naming client, I get the same error as before (see below).

nameclt list
Caught a TRANSIENT exception when trying to validate the type of the 
NamingContext. Is the naming service running?

The only modification I made in the /etc/omniORB.cfg file is to add the lines for InitRef (see below).

InitRef = NameService=corbaname::localhost
InitRef = EventService=corbaloc::localhost:1169/omniEvents

Also, I am not connected to the internet so my version of CentOS has not been updated from the base version, except for the boost libraries as recommended in Appendix J of the manual (http://sourceforge.net/projects/redhawksdr/files/redhawk-doc/1.9.0/REDHAWK_Manual_v1.9.0.pdf/download).

coder
  • 37
  • 11

1 Answers1

2

Looks like the issue is in your configuration. You've got the wrong port in your configuration file. It should be port 11169 however you've listed port 1169.

See: http://redhawksdr.github.io/Documentation/mainch2.html#x4-120002.6 for details.

A few other observations and tricks regarding omniOrb in case this was not the issue.

  • Sometimes omninames/omnievents can get into a bad state. The fix is to delete the log files created by omniNames and omniEvents and restart the services. They are located:

    /var/lib/omniEvents/*

    /var/omniNames/*

You'll need to be root to delete those files. I always forget where they are located and often do a "locate omni | grep -i log" to remind myself but you must do this as root since they are not visible to standard users.

  • While it should not matter, I've personally found that using 127.0.0.1 is more reliable than localhost. For some reason, using localhost within a VM in the configuration file has caused me problems in the past. Consider using 127.0.0.1 instead of localhost. This is what the current version of the Redhawk Manual recommends as well.

  • You mentioned you are using Redhawk v1.8.2. As an FYI, the latest REDHAWK version in the 1.8 series is currently v1.8.5 and 1.9.0 was also recently released.

Hopefully this gets you up and running!

Youssef Bagoulla
  • 1,229
  • 1
  • 7
  • 16
  • Thanks for the note about the wrong port for omniEvents. The documentation for version 1.8.2 specifically said to use port 1169, but I didn't realize it was a typo. After trying all of your steps, the one that finally fixed the problem was using 127.0.0.1 instead of localhost. Also, I realize the version 1.9.0 has been released, but because my computer is not connected to the internet it is extremely tedious to manually download all the dependencies to install the latest version. – coder Nov 14 '13 at 17:28