Failure to Create a Participant due to Insufficient Shared Memory Kernel Settings

If you are running RTI Connext DDS 5.1.0 or earlier, you may get this error message when starting your application:

[D0061|ENABLE]NDDS_Transport_Shmem_create_recvresource_rrEA:failed to initialize shared memory resource segment for key 0x405971
[D0061|ENABLE]NDDS_Transport_Shmem_create_recvresource_rrEA:failed to initialize shared memory resource segment for key 0x405973
[D0061|ENABLE]DDS_DomainParticipantPresentation_reserve_participant_indexI:!enable reserve participant index
[D0061|ENABLE]DDS_DomainParticipant_enableI:Automatic participant index failed to initialize.
PLEASE VERIFY CONSISTENT TRANSPORT / DISCOVERY CONFIGURATION.
DDSDomainParticipant_impl::createI:ERROR: Failed to auto-enable entity
DomainParticipantFactory_impl::create_participant():!create failure creating participant
create_participant error

If you are running RTI Connext DDS 5.2.0 or later, you may get this error message when starting your application:

[D0062|ENABLE]DDS_DomainParticipantPresentation_reserve_participant_index_entryports:!enable reserve participant index
[D0062|ENABLE]DDS_DomainParticipant_reserve_participant_index_entryports:Unusable shared memory transport. For a more in-depth explanation of the possible problem and solution, please visit https://community.rti.com/kb/osx510.

This error is caused by an insufficient number or size of shared memory segments allowed by the operating system. As a result, the DomainParticipant is unable to allocate enough resources and calculate its participant index which causes the error. In RTI Connext 5.1.0 and earlier, the participant will fail to be created, even if the participant has another usable transport intsalled. In RTI Connext 5.2.0 and later, however, the particpant will be successfully created as long as one of the installed transports is valid and usable. 

This problem occurs most frequently on OSX due to the default kernel settings that control the resources needed by the RTI Connext shared memory transport. Therefore, the rest of this article details the settings necessary for OSX. If you are using a different operating system and run into these errors, then you may have to find the equivalent settings in your specific environment.

The settings in this solution are a recommendation. If you have a small number of applications you can use more conservative settings if necessary. 

You can increase the shared memory resources of your machine either temporarily or permanently.

To increase the settings temporarily, you can run the following commands as user root:

/usr/sbin/sysctl -w kern.sysv.shmmax=419430400
/usr/sbin/sysctl -w kern.sysv.shmmin=1
/usr/sbin/sysctl -w kern.sysv.shmmni=128
/usr/sbin/sysctl -w kern.sysv.shmseg=1024
/usr/sbin/sysctl -w kern.sysv.shmall=262144

To increase the settings permanently, you will need to edit or create the file /etc/sysctl.conf. Creating or editing this file will require root permissions. Either add to your existing /etc/sysctl.conf file or create /etc/sysctl.conf with the following lines: 

kern.sysv.shmmax=419430400
kern.sysv.shmmin=1
kern.sysv.shmmni=128
kern.sysv.shmseg=1024
kern.sysv.shmall=262144

You will need to reboot the machine after modifying this file to have the changes take effect.

As a convenience, you can run the attached shell script, shmem_osx.sh (contained in shmem_osx.zip), to temporarily change the shared memory settings of your system. It will also ask you if you would like to make the changes permanent and will either create or append to /etc/sysctl.conf if you choose to have it do so. You must run the script as user root. 

Attachments: