Running iceoryx application without explicitely starting the RouDi daemon

[elBoberido]

Brief feature description

For ease of use, it is desirable to run an iceoryx application without taking care whether the RouDi daemon is already running.

Detailed information

The RouDi daemon performs multiple tasks:

• setting up the shared memory segments
• creating resources for thing like publishers/subscribers
• monitoring and cleaning up memory if applications are not gracefully terminated
• providing a discovery service Therefore it is required to be running when an iceoryx application is started.

For ease of use, it is desirable to run an iceoryx application without taking care whether the RouDi daemon is already running. There are multiple ways how this could be achieved

The user process forks a process for RouDi

• if there is already a running RouDi process the forked process silently exits
• once there are no more user processes left, RouDi shuts down
  • in order to prevent a shutdown right at the start, when no user processes are registered, the forked RouDi knows the pid of it's child process and waits (with a timeout) for this process to register
  • there is a race when RouDi shuts down and a new user process tries to for RouDi
    • this might be solvable with a smart algorithm
    • best place to do this might be were we currently check for a running RouDi
• this should be optional
  • by compile time, e.g. iox::runtime::PoshRuntime::initRuntime("app_name", iox::RouDi::TRY_FORK); or iox::roudi::RouDi::tryFork();
  • by run time and environment variable, e.g. export RUN_ROUDI_FROM_PATH=/home/foo/iox/build/iox-roudi; ./maypporRUN_ROUDI_FROM_PATH=/home/foo/iox/build/iox-roudi ./maypp
• how to deal with cmd line parameter
  • each user process forwards the cmd line parameter to the forked RouDi process
    • one does not know which RouDi wins the race when the cmd line parameter differ
  • always use the default config file from /etc
    • if a RouDi with different parameter is needed, it must be started manually
    • it might be necessary to extend the config file with option for log level, etc.
• when statically linked, each user process would be larger by a few MB due to the RouDi code
  • this could be circumvented when the environment variable option is used
    • forking would not be necessary anymore since we know the path to RouDi
    • we could use the POSIX system function which should also work on Windows

Using a custom launcher like iox run myapp, similar to ros2 run foo_package bar

• this launcher start RouDi if it is not already running
• we could also extend the iox process with plugins like iox list publisher for the most simple form of introspection
• harder to integrate in other frameworks like eCAL or ROS
• how it is done in ROS2

Use systemd as service manager

• similar to iox run myapp with systemclt start myapp.service
• needs a service file
• would take care of starting RouDi and everything else which is needed by the application
• the systemd readiness protocol be implemented in iceoryx without directly linking to systemd libraries
• on macOS launchd could be used and Windows probably has something similar

Move RouDi (or parts of it) into a kernel module

• because we can
• might not work due to mapping of the shm, etc; we need to check this
• might reduce context switches
• might work on Linux and especially on QNX (microkernel)
• higher safety/security risk
  • some of the safety guarantees from running as a user process are void
  • would make RouDi probably harder to certify

[lygstate]

Good to see, anything I can do for it?

[lygstate]

Brief feature description

For ease of use, it is desirable to run an iceoryx application without taking care whether the RouDi daemon is already running.

Detailed information

The RouDi daemon performs multiple tasks:

• setting up the shared memory segments
• creating resources for thing like publishers/subscribers
• monitoring and cleaning up memory if applications are not gracefully terminated
• providing a discovery service Therefore it is required to be running when an iceoryx application is started.

For ease of use, it is desirable to run an iceoryx application without taking care whether the RouDi daemon is already running. There are multiple ways how this could be achieved

The user process forks a process for RouDi

• if there is already a running RouDi process the forked process silently exits

• once there are no more user processes left, RouDi shuts down

  • in order to prevent a shutdown right at the start, when no user processes are registered, the forked RouDi knows the pid of it's child process and waits (with a timeout) for this process to register

  • there is a race when RouDi shuts down and a new user process tries to for RouDi

    • this might be solvable with a smart algorithm
    • best place to do this might be were we currently check for a running RouDi

• this should be optional

  • by compile time, e.g. iox::runtime::PoshRuntime::initRuntime("app_name", iox::RouDi::TRY_FORK); or iox::roudi::RouDi::tryFork();

Shoud be able add a parameter maybe a $uuid or $roudi_grou_id to roudi program, so that if we want running multiple roudi instance on single machine, such as we have two process group, both use roudi and we want they are not affected by each other, then we may want start idependent roudi process for each.

• by run time and environment variable, e.g. export RUN_ROUDI_FROM_PATH=/home/foo/iox/build/iox-roudi; ./maypporRUN_ROUDI_FROM_PATH=/home/foo/iox/build/iox-roudi ./maypp

• how to deal with cmd line parameter

  • each user process forwards the cmd line parameter to the forked RouDi process

    • one does not know which RouDi wins the race when the cmd line parameter differ

  • always use the default config file from /etc

    • if a RouDi with different parameter is needed, it must be started manually
    • it might be necessary to extend the config file with option for log level, etc.

• when statically linked, each user process would be larger by a few MB due to the RouDi code

  • this could be circumvented when the environment variable option is used

    • forking would not be necessary anymore since we know the path to RouDi
    • we could use the POSIX system function which should also work on Windows

Using a custom launcher like iox run myapp, similar to ros2 run foo_package bar

• this launcher start RouDi if it is not already running
• we could also extend the iox process with plugins like iox list publisher for the most simple form of introspection
• harder to integrate in other frameworks like eCAL or ROS

Use systemd as service manager

• similar to iox run myapp with systemclt start myapp.service
• needs a service file
• would take care of starting RouDi and everything else which is needed by the application
• the systemd readiness protocol be implemented in iceoryx without directly linking to systemd libraries
• on macOS launchd could be used and Windows probably has something similar

Move RouDi (or parts of it) into a kernel module

• because we can

• might not work due to mapping of the shm, etc; we need to check this

• might reduce context switches

• might work on Linux and especially on QNX (microkernel)

• higher safety/security risk

  • some of the safety guarantees from running as a user process are void
  • would make RouDi probably harder to certify

[elBoberido]

Shoud be able add a parameter maybe a $uuid or $roudi_grou_id to roudi program, so that if we want running multiple roudi instance on single machine, such as we have two process group, both use roudi and we want they are not affected by each other, then we may want start idependent roudi process for each.

I think this is unrelated to this issue, maybe we need to create another one for this. I also thought about adding something like the ROS_DOMAIN_ID environment variable, e.g. ROUDI_DOMAIN_ID. The value of this variable would be suffixed to all resource names, e.g. the name of the unix domain socket and the shm segment names, the lock files, etc.

@budrus @elfenpiff @dkroenke @mossmaurice @MatthiasKillat @FerdinandSpitzschnueffler what do you think about this?

[elBoberido]

Good to see, anything I can do for it?

I think we first have to discuss to pros and cons of the approaches but from my gut feeling the option with the environment variable and the system call might be the cleanest solution. Currently we print a warning that RouDi is not found and that the application is waiting but we could also add another line to add the environment variable to the .bashrc to autostart Roudi.

Once we agree on the implementation, would you have time for the implementation? We would of course guide you for the right locations in our code base.

[t0ny-peng]

@elBoberido Sorry for jumping in. I happened to talked to @dkroenke this morning about running Roudi in the automated test. We have several integration tests that expect a running Roudi instance. The solution we came up with is to check if Roudi is running and, if not, using Python to start Roudi as daemon process, i.e., adopted by init.

That being said, I fully second your opinion. It would be nice to have a real Iceoryx Daemon instead of using tricks like this or adding & to the end of command each time.

[xixioba]

Is there a solution so far to complete this issue?🤔

[elfenpiff]

@xixioba This feature is definitely on our road map but I doubt that we are able to implement this in the upcoming weeks.

How urgent is this feature on your side?

[xixioba]

@elfenpiff It's not urgent, I'm glad it's on the roadmap

[Aarivvk]

@elBoberido I can have a look and tryout somethings as mentioned in the issue.

[elBoberido]

@vinayakumarMurganoor great. I assigned the issue to you. Don't hesitate to ask if you have questions.