eclipse-iceoryx / eclipse-iceoryx/iceoryx
RouDi terminating application not via SIGTERM (because of EINTR)
- Dominant language
- C++
- Stars
- 2.2k
- Forks
- 492
- Avg merge
- 18h 57m
- Merged PRs (30d)
- 1
Description
## Brief feature description
When roudi is terminating applications it sends a SIGTERM to the application.
This comes with the following problems:
* When the application does not have a signal handler registered it is terminated without cleaning up its resources. Resources like named semaphores, shared memory, files are then remaining and may lead to misbehavior when the application is restarted
* When the application has registered a signal handler it can happen that the application is waiting in a blocking call. This blocking call is returning then with `EINTR` but since the common suggestion is to recall the posix call when this signal comes, the application remains in that blocking call. So RouDi will kill the application after 30 seconds with SIGKILL which again may lead to resource leaks or even worse, the application continues after the blocking call and access non available shared memory resources which lead to a segfault or undefined behavior.
## Detailed information
When one thinks about it, RouDi does not need to terminate the application but it has to ensure that the applications runtime is destroyed. One could rewrite the posh runtime so that the user is informed that RouDi requests a termination and only when this request is ignored RouDi calls SIGKILL.
It could look like:
```cxx
auto runtime = iox::posh::createRuntime();
// ...
while( !runtime.isTerminationRequested() ) {
// do sending and receiving stuff
}
// here the runtime could be recreated if a reconnect to roudi is wished.
// as alternative, useful when one uses the listener
runtime.waitForTerminationRequest();
```
Contributor guide
Research direction
Start by tracing RouDi's application-termination flow and the posh runtime behavior described in the issue. No files or tests are named, so identify where SIGTERM is sent and where runtime termination requests could be exposed. Done means applications can observe a termination request, clean up or reconnect, and RouDi still uses SIGKILL only when the request is ignored.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- distributed-systems, operating-systems
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100