Introduction:
main– an executable(a c++ code that was compiled using g++). This is a big program, which shouldn’t stop running. if for any reason it stops, we would like to run it again.
run.sh – a shell script. run.sh calls main. if main stops running, its responsibility is to run main again. basically implements a watchdog. to try to avoid oom killer to kill also run.sh when main is killed (because it uses a lot of memory), I tried to find a solution on the internet and encountered the following:
the script executes main using the setsid command, meaning main will run in a different process group than run.sh
my_vm– a debian 11 vm
big_memory – an executable, simply a code with an infinite while loop, that calls malloc to allocate memory.

I tried to cause main to crush from allocating too much memory, but it is complicated. So I used the big_memory executable, which for my situation is good enough.

Scenarios:
Scenario 1(the bad scenario):
When my_vm boots, through various scripts and cronjobs, it runs run.sh.
run.sh calls main, and mainis running now(blocks run.sh from executing its next command).
Then I run big_memory from the terminal. After a while, because big_memory allocates memory non-stop, oom killer is invoked by some process. oom killer decides to kill main, but also decides to kill run.sh, and thus main doesn’t being restarted.

Scenario 2(the good scenario):
I run myself run.sh in the terminal. I call it to run in the background, using & symbol.
run.sh calls main, and main is running now.
Then I run big_memory from the terminal. After a while, because big_memory allocates memory non-stop, oom killer is invoked by some process. oom killer decides to kill main, and now it doesn’t kill run.sh. so when run.sh sees main crushed, it runs it again and everything is ok.

I ran the 2 scenarios several times, each time the result is the same.

So my question is, what is the difference between scenario 1 and scenario 2? why my solution works only if run.sh was called by myself through terminal, and doesn’t work if run.sh was called while the vm was booted?

I described the current solution above- run.sh executes main using setsid, meaning it will run in a different process group than run.sh