DDS Linux RHEL 5.8 Requires superuser?

7 posts / 0 new
Last post
Offline
Last seen: 3 years 10 months ago
Joined: 11/30/2012
Posts: 18
DDS Linux RHEL 5.8 Requires superuser?

 

We are using RTI DDS on Redhat Enterprise 5.8 64-bit server and the only way we seem to be able to get DDS to work is to run our app as superuser, which we'd prefer not to do.  Any suggestion on how to get around this?

Gerardo Pardo's picture
Offline
Last seen: 15 hours 35 min ago
Joined: 06/02/2010
Posts: 601

Hi,

I am not aware of such situation but I am also not familiar with the specifics and configuration of the Red Hat Enterprise Server.  

What do you mean by "only way we seem to be able to get DDS to work".  Are you getting errors if you do not run as super user?  Or is is that the applications run but they do not communicate.

Assuming the problem is lack of communications does this occur when both applications are running on the same computers or in different computers?

My first instinct would be to suspect it is some sort of Operating System security setting that is limiting the use of shared memory or UDP sockets by RTI DDS.

To determine is this is the case I would use the bundled rtiddsping and rtiddsspy  applications. If you run then in the same computer they will use shared memory to communicate. If they communicate on the same computer as super user but not as normal user, then I would suspect the Redhat server is placing some restriction on the use of shared memory by regular applications. If this is indeed the case you can try running them passing the option "-transport 1"  which will force them to use just UDP. As in:

On none terminal window:

annapurna:RTI500 gerardo$ ndds.5.0.0/scripts/rtiddsspy -transport 1 -print

RTI Data Distribution Service Spy built with NDDS version 1.6a.00--C1.6a.00--C++1.6a.00
Copyright 2012 Real-Time Innovations, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NddsSpy is listening for data, press CTRL+C to stop it.

source_timestamp   Info  Src HostId  topic               type              
-----------------  ----  ----------  ------------------  ------------------  
1354295349.017272  W +N  0A061079    PingTopic           PingType          
1354295350.017548  d +N  0A061079    PingTopic           PingType          
number: 1
1354295351.017776  d +M  0A061079    PingTopic           PingType          
number: 2
1354295352.017927  d +M  0A061079    PingTopic           PingType          
number: 3
1354295353.018073  d +M  0A061079    PingTopic           PingType          
number: 4

On a separate terminal  window:

annapurna:RTI500 gerardo$ ndds.5.0.0/scripts/rtiddsping -transport 1

RTI Data Distribution Service Ping built with NDDS version 1.6a.00--C1.6a.00--C++1.6a.00
Copyright 2012 Real-Time Innovations, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Sending data...   value: 0000000 
Found 1 additional ping subscriber(s).
Current subscriber tally is: 1
Sending data...   value: 0000001 
Sending data...   value: 0000002 
Sending data...   value: 0000003 
Sending data...   value: 0000004 

 

If the lack of communication occurs between different computers (or in the same computer even when you use the "-transport 1" option). Then I would suspect there is either a firewall or some restriction placec by the operating system on the application opening the ports.

Gerardo

Offline
Last seen: 3 years 10 months ago
Joined: 11/30/2012
Posts: 18

Thanks for the response. Sorry for not including more info up front.  Was hoping it was a simple solution to a known issue.  :-)

To clarify, the problem only occurs between different computers - it works fine locally.  And, by not working I mean that discovery appears to be only partially completed.  On a non RHEL system running the analyzer we can see the paticipants but not the publisher/subscribers.  It appears the same number of ports (multicast discovery) are being opened whether we're superuser or not.  When not running in superuser I see the following errors:

DDS_XMLParser_parse_from_file:RTI0x20f4402:Loading : USER_QOS_PROFILES.xml
[1354296316.835918] rR00000102701
  RTINetioSender_addDestination:RTI0x209000c:no transport for request
[1354296316.836385] rEvt000102701
  RTINetioSender_addDestination:RTI0x209000c:no transport for request
[1354296316.837193] rEvt000102701
  RTINetioSender_addDestination:RTI0x209000c:no transport for request
[1354296316.837593] rEvt000102701
  RTINetioSender_addDestination:RTI0x209000c:no transport for request
[1354296316.838205] rEvt000102701
  RTINetioSender_addDestination:RTI0x209000c:no transport for request
[1354296316.838709] rEvt000102701
  RTINetioSender_addDestination:RTI0x209000c:no transport for request
[1354296316.839250] rEvt000102701
  RTINetioSender_addDestination:RTI0x209000c:no transport for request

gianpiero's picture
Offline
Last seen: 2 months 1 week ago
Joined: 06/02/2010
Posts: 177

Hi Jhewell,

I am just wondering if RHEL 5.8 comes with SELinux enabled by default. You can check with getenforce (as root: it returns Enforcing or Disabled). 

SELinux may prevent the standard user creation of sockets. 

Best,

 Gianpiero

Offline
Last seen: 3 years 10 months ago
Joined: 11/30/2012
Posts: 18

Gianpiero -

Good idea, but I had already tried that.  It is set the same (Permissive) for both su and normal.  I even tried disabling SELinux altogether.

Gerardo Pardo's picture
Offline
Last seen: 15 hours 35 min ago
Joined: 06/02/2010
Posts: 601

Hi,

This kind of partial-discovery situation is consistent with what you would see when you have a firewall.  Analyzer running on another computer would see the participant in the RHEL computer because the RHEL application is pushing its ParticipantData out via multicast, but not the rest of the Endpoints (DataWriters or DataReaders) because they are only sent when the RHEL application discovers the other participants and that will not happen if RHEL has a firewall. Maybe when the application is running as root and listens to a port the OS automatically configures the firewall to let the traffic through but otherwise that does not happen...

If you run analyzer on the RHEL machine and a DDS application on the other (non RHEL) do you see the partitipant being discovered? If not it would indicate that the RHEL firewall is blocking the multicast traffic.

Can you try disabling the firewall and seeing if that makes the problem go away? Not sure if this is the right command on RHEL 5.8 but in other versions of RedHat this will do it:

service iptables stop

If it turns out it is indeed a firewall problem then you can use this spreadsheet to compute the UDP ports used by RTI Connext DDS to determine which ports you should open on your firewall for the DDS domain IDs you are using.

Gerardo

Offline
Last seen: 3 years 10 months ago
Joined: 11/30/2012
Posts: 18

 

Thanks to all for the help.  The issue was with the permissions for some of the files on that system.  Once I updated the executables and USER_QOS_PROFILES.xml to the correct owner/permissions the problem was resolved.  This included making sure all the ndds libraries were accessible.