eclipse-iceoryx / eclipse-iceoryx/iceoryx

RouDi terminating application not via SIGTERM (because of EINTR)

Open
#1,413 2 comments 0 reactions 0 assignees View on GitHub
bug technical debt
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.