fork () creates a child process.  The original program is a parent.  The new process is a child.  In this way, the processes on a Linux system form a hierarchy or a tree.  There are system calls to look up who your parent is or who anybody else's parent is, or to look up who your children are, or who anybody else's children now.

The "normal order of things" is for a process to wait for all of its children to die before dying itself.

Sometimes, in very specific circumstances, you don't want this, and you do it on purpose.  But most of the time when a parent dies for the child, this is due to a bug.

When a child dies, the parent has to wait for it, by issuing a wait command.  If you wait for a child that is already dead to die, then wait returns immediately and the child is registered for dead.  If the child is not dead, then wait just hangs there until the child.  Again, child dies, parent waits, is how things are supposed to happen.

If a parent dies before a child, its children are then called "orphan" processes.  They still exist, they still run their program, but they have a new parent.  There is a PID on the system whose job it is to manage these orphan processes, and that PID becomes the new parent.

When a child dies, it becomes a "zombie" process.  The termination of that child is not fully processed UNTIL the parent waits for it.  And this dead process still shows up on process lists even though it's dead; its program has ended.  If a parent gets in the habit of not waiting for its dead children, you could end up with a whole mess of zombie processes.

If a parent dies, the "zombies" become "orphan zombies".  However, their new adoptive PID will immmediately issue the wait command and let the zombies finish dying.

What's the difference between kill and kill -9?

Processes can send and receive signals to and from other processes and even to itself.  One of these is SIGTERM, the termination signal.  (Represented by the "kill" command.)  Upon receiving SIGTERM, a program by default will die BUT code can be written though it does something else upon receipt of SIGTERM.

Another signal is SIGKILL (represented by "kill -9").  SIGKILL forcibly terminates the program, and this cannot be subverted or reprogrammed.