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?
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?
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:
On a separate terminal window:
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
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
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
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.
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:
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
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.