Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add flag to RouDi to disable killing connected processes #2248

Closed
kozakusek opened this issue Apr 11, 2024 · 4 comments
Closed

Add flag to RouDi to disable killing connected processes #2248

kozakusek opened this issue Apr 11, 2024 · 4 comments

Comments

@kozakusek
Copy link
Contributor

Brief feature description

Add flag to iox-roudi, (-d, --do-not-kill) which would disable sending SIGETERM and SIGKILL during shutdown.

Detailed information

Currently, when iox-roudi is shutting down it kills all processes known to it.
I've encountered a situation in which connection with RouDi is only a part of the process lifetime and I definitely don't want it to be killed if RouDi shuts down.

From what I understand it shouldn't be much work since there is already a flag in the configs that can be used to disable this. It should suffice to add a cli flag and push it through.

@elBoberido
Copy link
Member

@kozakusek can you share some details of your use case?

The experimental Node API might be interesting for you

This API does not use a static runtime and when the Node is destroyed (all endpoints need to be destroyed beforehand) it de-registers from RouDi and RouDi can be shut down. Later you can re-start RouDi and create new nodes.

Currently, only Publisher, Subscriber and the WaitSet is available with the experimental API. If you also need Server, Client and Listener, it isn't too complicated to add them. You can either try to add it yourself, wait till someone else implements it (it is on my quite long todo list) or ask these new guyes from ekxide to do it ;)

@kozakusek
Copy link
Contributor Author

I have long running processes (days+) that might only want to communicate during start-up (or some catch-up) and basically go on with their life. In the meantime I want to restart the daemon to for example change the config.

The other thing: I want to have different roudi configs for different tests in one junit suite..

Those are not major issues, however the flag whould be a nice thing to have, especially when there is already a filed in the config that allows this behaviour

@elBoberido
Copy link
Member

elBoberido commented Apr 13, 2024

In this case the new experimental API is exactly what you need. You can shut down RouDi once all the nodes are destructed, restart RouDi with a different config and create new nodes to connect to the new RouDi. While multiple RouDi can run in parallel, it is not yet possible to have nodes connected to multiple RouDis in the same process at the same time. This is only possible in tests. Here you can check how to use multiple RouDi in the tests.
https://github.com/eclipse-iceoryx/iceoryx/blob/master/iceoryx_posh/test/integrationtests/test_posh_experimental_node.cpp#L570

I don't like to expose this option to the default RouDi since it only partially does what you need and it might result in unexpected behavior. For example, if you would restart RouDi and run a process which wants to subscribe to a publisher which was started with the previous RouDi, this would not be possible, leaving the users confused and finally bug tickets would appear on this repo.

Furthermore, since the long running process would not destruct the static runtime, the shared memory would not be released since there are still open file descriptors. The files in /dev/shm will be removed but the memory will not be obtained. You can test this with pkill -9 iox-roudi and deleting all iox_ files from /dev/shm while your process is running. The communication via iceoryx continuous to work, one just cannot subscribe to or unsubscribe from existing connections but allocating chunks and publishing still works. This means you would run out of memory sooner or later since the runtimes keep the memory mapped.

If you do not know when all nodes would be destroyed and therefore also not when to stop RouDi, there are multiple options

  • monitoring app
    • subscribe to the process introspection topic
    • when there are no other processes listed except roudi and your monitoring app, destruct the node in the monitoring app
    • send a sigterm to the RouDi PID
  • add option to let RouDi shut down automatically once the last process unregisters

@kozakusek
Copy link
Contributor Author

Thanks for the explanation and bringing up the issues that might arise from this change.
I will try the Node API and if it doesn't work out I will just think of some local workarounds.

@kozakusek kozakusek closed this as not planned Won't fix, can't repro, duplicate, stale Apr 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants