I want to ask what is the cause of the following problem. In our C program we can find that the following process isn't working well. We run this program on Linux

We have a program that executes two external programs such pr1.exe and pr2.exe (once these programs have started, they will run continuously) , this program execute the following steps:

1. Create a thread to run pr1.exe with the system() instruction
2. Create a thread to run pr2.exe with the system() instruction

But when we try to execute pr2.exe, we can see that the system instruction return the code 512 and the value of WEXITSTATUS is 2 and if I execute lsof instruction a can see that:
pr2 is associated with pr1
like that:
1509 /tmp/pr1.exe /tmp/pr2.exe

Only if we kill the pr1.exe process, pr2.exe starts running and then pr1.exe restarts (because the program is designed to restart a program if it cannot run)

Another solution is to put a wait time between processes. like that:

1. Create a thread to run pr1.exe with the system() instruction
2. wait(time)
3. Create a thread to run pr2.exe with the system() instruction

The same problem is reproduced if we change the order of execution of the programs. In this case pr2.exe is executed and pr1.exe is not executed because it is associated with pr2.exe.
If we change system() to a branch and some execl statements, we have the same problem

would be nice to see the actual code?
system() waits for the end of the execution, so if you want to start processes you need to do it differently. But it also may depend on the executables themselves.

You might try `system("nohup program1.exe </dev/null >/dev/null 2>/dev/null &")`

Note: system("pr2") returning 512 might mean errcode=2 from pr2

It is my understanding that the system() call operates at a process level. So, it will block the entire process including all of its threads. I do not believe that this approach to running a child-process is intended to be thread-friendly. You will need to select another approach.

@OP: Nonetheless you are allowed to produce a little example program that helps us reproduce the problem.

The problem with the system in this case was that the main thread had immediately launched the first thread where the first program was executed, decompressed the second program, created the exe using the fopen instruction, but what happened was that the first program It remained in possession of this second, and when launching the second thread so that the second program would be executed in parallel, the system told us that it could not execute it since it was in possession of the first.

The solutions have been to set a small waiting time before creating the exe and in the event that this time is not enough, then as the main thread knows if a program is running or not what it will do is delete the exe of the program that it doesn't run, unzip it again and run it again

I hope that you understand what you're saying.