I looked this question up on SO and Google and just about every time someone asks this, it seems the answer is "no" and that you have to go out of your way to ensure the children are terminated with the parent. And yet, that is not my experience, at least not in Ubuntu running under WSL 2. When I terminate my parent process with a SIGINT (by hitting Ctrl-C), all my child processes that I forked go away, by default.
The one place where I found some information that might corroborate this was here where is states:
When we invoke fork(), it creates a child process with a unique process ID and a copy of the signal dispositions from its parent process. However, when we call the exec() family of methods, it replaces the process image and resets the signal dispositions to default.
This means that the signal behavior in the child process after exec() does not share with that of the parent process anymore. Therefore, if we send the signal to the parent process after calling exec(), it will naturally not propagate.
Unless I am misinterpreting this, it seems to be saying that the idea that children processes are not terminated with their parent process is only true if you are calling exec after fork, which I am not.
So, is that the correct interpretation?
When I terminate my parent process with a SIGINT (by hitting Ctrl-C), all my child processes that I forked go away, by default.
This happens because both processes are in the same process group and you killed the group leader, see SIGINT and child processes. Be aware that different shells set process groups and job control in very different ways.
What you cited looks like Baeldung tutorial. First part:
When we invoke fork(), it creates a child process with a unique process ID and a copy of the signal dispositions from its parent process. However, when we call the exec() family of methods, it replaces the process image and resets the signal dispositions to default.
Only means that as you recover the code with exec naturally custom signal handlers can not be preserved. The truth is that only custom signal handlers are reset to default (see Is it possible for a signal handler to survive after "exec"?).
This means that the signal behavior in the child process after exec() does not share with that of the parent process anymore. Therefore, if we send the signal to the parent process after calling exec(), it will naturally not propagate.
These last sentences are somehow weird. The first only means (if I understand well) that each process has its own signal management. The second is false/misleading. There is no propagation and that is true, because there is no signal propagation at all. But as I already stated, there is a concept of process group that may affect the way process survived.
children processes are not terminated with their parent process is only true if you are calling exec after fork,
Again, child termination has nothing to do with fork/exec. fork creates a child that's all. exec changes process address space and some things associated to it (as signals). Termination of a process is something else not related to these. Start reading POSIX Process Groups.