Process Flag 1: Forked but didn't exec (use case?)

Question

In the man page for ps, it lists process flag 1 as "process forked but didn't exec". What would be a common use case/situation for a process to be in this state?

Answer 1

This sentence refers to the fork and exec system calls¹. The fork system call creates a new process by duplicating the calling process: after running fork, there are two processes which each have their own memory¹ with initially-identical content except for the return value of the fork system call, the process ID and a very few other differences. The exec system call loads a program image from a file and replaces the existing process's memory by that image.

The way to run a program in the usual sense is to call fork to create a new process for the program to run in, and then call exec in the child to replace the copy of the original program by the new program's code and data. That's the most common usage of fork (often with a few things done before exec like setting up file redirections).

Running exec without having done a fork can be seen as an optimization of doing fork+exec and having the parent do exit immediately afterwards. It isn't exactly equivalent because fork+exec/exit changes the parent of the resulting program, whereas a straight exec doesn't.

Linux's process flag 1 signals processes that didn't call exec since they were forked by their parent, i.e. children (or grandchildren, etc.) of the original process of their program. Calling fork without calling exec has several uses. (This is not an exhaustive list, just some common use cases.)

• Some programs exploit multiple processors. This can be done either by running multiple threads in the same process (then all the threads share memory) or by running separate processes on each processor (then they don't share memory).
• Running separate processes is a way to isolate some tasks. For example, Chrome keeps each tab or each small group of tabs in a separate process; this way, if a tab is hung or crashes, or if a web page triggers a security hole, that doesn't affect tabs displayed by other processes. Separate processes can also be useful to perform different tasks with different privileges; for example the OpenSSH server runs most of its code as an unprivileged user and only performs the final login stage as root. Shells use fork to implement subshells (parts of the script where variables, redirections, etc. don't affect the main script).
• Daemons usually start by “double forking”: when the program runs, one of the first things it does is fork, and then the parent exits. This is the inverse of the exec “optimization” I mentioned above, and is done to isolate the daemon process from its original parent, and in particular to avoid blocking the original parent if it was waiting for its child to finish (as happens e.g. when you run a program in a shell without &).

¹ _{There are nuances that do not matter here and are beyond the scope of this answer.}