I read the earlier question Differences between fork and exec but it left me with some doubts.
When using fork() and you call exec on a child, the new process created by exec is still a child right?
Does killing the parent process kills the child too?
In the drawing/example shown in the top answer, he calls wait/waitpid because if the parent process terminates first, the child process dies and then you get partial or no output for the ls command, is that correct?
exec replaces the currently executing process image with a new one. So yes, the child is sill a child process (it is actually the same process.)
No, killing the parent does not kill the child (the child is orphaned).
Killing the parent process does not kill the child. When the child process calls an exec function, it is still a child process.
In the example from the linked question, the flowchart is roughly describing the process that a shell uses to invoke commands. Unless the command is back-grounded, the shell - the parent process - will wait until the child process terminates before continuing to read commands. Otherwise waiting on the child wouldn't be necessary.
See also this question.
When using fork() and you call exec on a child, the new process created by exec is still a child right?
When calling exec on the child the new process is handled by the child. The child's process is replaced by the exec call.
Does killing the parent process kills the child too?
It's possible for the child process to die when the parent process dies (at least in Linux) by having the OS send a signal, but otherwise it just lives on.
he calls wait/waitpid because if the parent process terminates first, the child process dies and then you get partial or no output for the ls command, is that correct?
You'd want to wait for the child process (as in the example you pointed to) so that: a) you can correctly terminate your child process when finished b) the child process has access to all the resources of the parent... meaning if your child has a file handle opened by the parent and the parent exits, but the child assumes that the file will be open as long as it's running, bad things will happen.
Take a look at this quick example: First, look at the output of a process listing:
mike@linux-4puc:~> ps
PID TTY TIME CMD
18577 pts/2 00:00:00 bash
18643 pts/2 00:00:00 ps
Then run this little program:
void main()
{
if(fork()){
printf("parent print");
}
else
while(1);
printf("done");
}
Here you'll have the parent print the message "parent print" then "done". Check a "ps" listing when it's done and you'll see a new process in the tree hanging out:
mike@linux-4puc:~> ps
PID TTY TIME CMD
18577 pts/2 00:00:00 bash
18673 pts/2 00:00:02 a.out
18678 pts/2 00:00:00 ps
That a.out is the child, sitting forever in the while loop while the parent terminated.
.. the new process created by exec is still a child right?
Yes, it's still the child.
Does killing the parent process kills the child too?
No. If parent dies for whatever reason and child is still executing, then the child will be adopted by the init process (process ID=1) process which will become the new parent of this orphan process.
calls wait/waitpid because if the parent process terminates first, the child...
waitpid/wait is for notifying the status of the child to the parent. Note that, if the parent process has many children then it usually waits for any child unless you specify the process ID of a particular child.
