Failure in creating domain participant

3 posts / 0 new
Log in or register to post comments
Last post
Sun, 03/06/2011 - 11:42
#1
yman
Offline
Last seen: 13 years 8 months ago
Joined: 03/06/2011
Posts: 1
Failure in creating domain participant

Hi,

 

My application has many processes, currently all of them are running in a single machine. Each one creates a domain participant using default QOS:

 

participant = DDSDomainParticipantFactory::get_instance()->

                       create_participant(

                        1,                              /* Domain ID */

                        DDS_PARTICIPANT_QOS_DEFAULT,    /* QoS */

                        NULL,                           /* Listener */

                        DDS_STATUS_MASK_NONE);

 

 

After starting several processes, I get these errors when starting a new process:

 

...

[D0001|ENABLE]NDDS_Transport_Shmem_create_recvresource_rrEA:failed to initialize shared memory resource mutex for key 0xb01ed7

[D0001|ENABLE]RTIOsapiSharedMemoryMutex_create:OS semget() failure, error 0X1C

[D0001|ENABLE]NDDS_Transport_Shmem_create_recvresource_rrEA:failed to initialize shared memory resource mutex for key 0xb01ed9

[D0001|ENABLE]RTIOsapiSharedMemoryMutex_create:OS semget() failure, error 0X1C

[D0001|ENABLE]NDDS_Transport_Shmem_create_recvresource_rrEA:failed to initialize shared memory resource mutex for key 0xb01edb

[D0001|ENABLE]DDS_DomainParticipantPresentation_reserve_participant_indexI:!enable reserve participant index

DDSDomainParticipant_impl::createI:ERROR: Failed to auto-enable entity

pkill DomainParticipantFactory_impl::create_participant():!create failure creating participant

DomainParticipantFactory_impl::create_participant():!create failure creating participant

 

 

Any suggestion on why it happens and how to avoid it ?

Thank you.

Organization:
Keywords:
Top
Wed, 03/09/2011 - 11:53
fabrizio
Offline
Last seen: 5 months 3 weeks ago
Joined: 03/09/2011
Posts: 4

The error you are getting is generated by the low level shared memory transport and is reporting that the system is running out of shared object handles available for semaphores.

According to the documentation of the semget function:

 

ENOSPC     A semaphore set has to be created but the system limit for the maximum number of semaphore

                  sets  (SEMMNI),  or  the  system  wide  maximum  number  of  semaphores (SEMMNS), would be

                  exceeded.

 

Depending on the system you are using, the default shared memory objects (semaphore and mutex) that an application can create varies quite a lot. You can always modify those defaults using the 'sysctl' command.

 

Use the command:

    sysctl -a

to see all your system configurable parameter.

 

Most of the values you see are platform dependent.

So, for example, for Linux RHEL5, you can control shared memory limits with the following properties:

 

 

- kernel.shmmni

 

- kernel.shmall

 

- kernel.shmmax

and semaphore settings with:

 

- kernel.sem
This last parameter reports 4 fields: 
 SEMMSL - The maximum number of semaphores in a sempahore set
 SEMMNS - The maximum number of sempahores in the system
 SEMOPM - The maximum number of operations in a single semop call
 SEMMNI - The maximum number of sempahore sets  

 

On Mac OS, the shared segment settings are controlled by:

 

- kern.sysv.shmmax

- kern.sysv.shmmin

- kern.sysv.shmmni

- kern.sysv.shmseg

- kern.sysv.shmall

 

and the semaphore settings by:

 

- kern.sysv.semmni

- kern.sysv.semmns

- kern.sysv.semmnu

- kern.sysv.semmsl

- kern.sysv.semume

 

 

 

Try to increase those values (note that those values can be accessed also from the /proc filesystem).

 

You can check also the list of semaphores and mutex in use using the command:

    ipcs

You can use the command 'ipcrm' to delete a shared object. Unfortunately there is no easy way to recognize which are the objects used by RTI DDS (the object ID is obtained as a function of domain ID, participant index and kind of data writer/reader).

 

Fabrizio

Top
Fri, 02/21/2014 - 13:19
rip
rip's picture
Offline
Last seen: 1 day 3 hours ago
Joined: 04/06/2012
Posts: 324

If you are running into this problem with 5.1.0 on MacOS X (Mavericks), create an /etc/sysctl.conf file with these values:

kern.sysv.shmmax=16777216
kern.sysv.shmmin=1
kern.sysv.shmmni=128
kern.sysv.shmseg=32
kern.sysv.shmall=4096

 

I set mni to 256, probably 32 is probably sufficient for an application with a single Domain Participant, but I didn't test it.

 

 

Top