I’m working on a Debian 11 VM where I have a C++ executable (main) that should run continuously. If main stops for any reason, a shell script (run.sh) is responsible for restarting it. To prevent the Out-Of-Memory (OOM) killer from terminating both run.sh and main, I’m using the setsid command to start main in a separate process group.

Problem:
I’ve observed different behaviors in how the OOM killer interacts with run.sh and main based on how run.sh is executed:

Scenario 1 (During VM Boot):

• run.sh is triggered automatically by scripts/cron jobs when the VM boots.
• run.sh calls main, which then blocks run.sh.
• I simulate a memory overload using a separate process (I called it big_memory_allocator), causing the OOM killer to intervene.
• The OOM killer terminates both main and run.sh, preventing run.sh from restarting main.

Scenario 2 (Manual Execution):

• I manually start run.sh from the terminal and run it in the background (run.sh &).
• The same memory overload is simulated, and the OOM killer is invoked.
• This time, only main is terminated, and run.sh successfully restarts it.

Question:

• What causes the difference in behavior between these two scenarios?
• Why does the OOM killer terminate both main and run.sh during boot, but not when run.sh is manually executed from the terminal?
• How can I ensure that run.sh consistently restarts main regardless of how it is triggered?