Vfrdtyky

I'm a beginner in C and I'm struggling in understanding the execve function in C to invoke a child process to loads and runs the executable object file.

We know that execve returns to the calling program only if there is an error such as not being able to find filename, so it is called once and never returns.

Here is my question, if we fork a child process to call execve but since execve never return, it will be always executing something if everything is OK, which means that the child process will never get terminated, so how can parent process reap this child process? below is sample code

if ((pid = Fork()) == 0) { /* Child runs user job */

   if (execve(argv[0], argv, environ) < 0) {      -------->line 2

      printf("%s: Command not found.n", argv[0]);

      exit(0);

   }

}



/* Parent waits for foreground job to terminate */

if (waitpid(pid, &status, 0) < 0) {  ------------> but the child process never terminated

   printf("waitpid error");

}

so in line 2, execve(argv[0], argv, environ) never return, so the child process is never terminated?

Your program foo, will start some child process to run some other program, bar,
and you want it to do this with the basic system calls fork and execve

Let's call your initial foo process p1. (This stands for some pid.)

First, you will call fork.
That creates a child process of p1 that is running another instance of foo
Call that child process p1.1.

p1.1 is running foo. But you want to run bar. So immediately in p1.1, foo calls execve(path/to/bar ...).
This replaces the instance of foo that p1.1 is running with an instance of bar. Then your
child process p1.1 is running bar, as you want.

Be clear about this:-

execve(path/to/bar ...) does not start bar in a new sub-process of
p1.1, and leave p1.1 still running the post-fork instance of foo. Instead, execve(path/to/bar ...) replaces
that instance of foo with an instance of bar in process p1.1. After fork, but before execve,
we have:

p1[foo] -> p1.1[foo]

And after execve we have:

p1[foo] -> p1.1[bar]

not:

p1[foo] -> p1.1[foo] -> p1.1.1[bar]

You can see then that execve cannot return success to its caller, p1.1[foo],
because if execve succeeds, then p1.1[foo] no longer exists.
And of course execve cannot return success to p1[foo], because p1[foo] did not call it.

since execve never return, it will be always executing something if everything is OK

No. execve replaces p1.1[foo] with p1.1[bar] and does not return, because the caller no longer exists. Then p1.1[bar] runs until it terminates.

p1.1[bar] will terminate sooner or later in one of the ways
that any program terminates: it will run until a normal exit, or it will
be killed by a signal, or it might possibly call abort of its own volition.

How can the parent process (p1) reap this child process (p1.1)?

Firstly, it doesn't have to. Once p1[foo] has started p1.1, it could,
if that's what you want, just forget about p1.1, get on with other business
if it has any, and eventually exit. If p1 terminates before p1.1, then p1.1
becomes an orphan process.
An orphan process is immediately adopted as a child by the init process. So
if nothing terminates it in the meantime, p1.1 will be reaped when init terminates, in system shutdown.

But very likely, you don't want to abandon orphans and you do want foo to know the exit status of the child bar. In that case,
p1[foo] must sooner or later call wait/waitpid to learn now p1.1
ended, and then act accordingly.

In the meantime, p1[foo] may well be communicating with p1.1[bar] using some
form of inter-process communication. And/or p1[foo] might
be noting the elapsed time while p1.1[bar] still has not ended. In one of these ways, or others, p1[foo] might determine
that p1.1[bar] is in trouble, has gone on for too long, and decide to kill p1.1 itself.
When p1.1 gets killed - whoever does it - or ends by its own volition, wait/waitpid will return that information to p1[foo], and then it
may exit itself, or carry on doing something else.

In a comment you enquired:

can't we design [execve] like : return 1 if the child process is terminated?

A system call like that can certainly be designed, and already exists, but it cannot
be a non-blocking system call that replaces the calling process, which is what execve
is. It would be a blocking system call that runs a sub-process of the calling
process and returns the sub-process's exit status to the parent. The one that does that is system

From man page of execve:

On success, execve() does not return, on error -1 is returned, and
errno is set appropriately.

To receive return value from child process, need to use wait

In the simple case, the child process will eventually terminate whether or not you call exec successfully. So this is easy… just have the parent wait for every child it creates with fork.

However, there is a technique to propagate failures from exec to the parent. The technique works like this:

1. Create a pipe.


2. Fork.


3. In the child process, close the read side of the pipe. Mark the write side as close-on-exec.


4. Call exec in the child. If it fails, write a failure message to the pipe, and exit.


5. From the parent process, close the write end of the pipe and read from the read end.

If exec succeeds, the parent process will read no data and just get EOF. If it fails, the parent will read the error message.