Linux – Is the PID of a child process always greater than the PID of its parent on Linux

When a process exits, all its children also die (unless you use NOHUP in which case they get back to init).

This is wrong. Dead wrong. The person saying that was either mistaken, or confused a particular situation with the the general case.

There are two ways in which the death of a process can indirectly cause the death of its children. They are related to what happens when a terminal is closed. When a terminal disappears (historically because the serial line was cut due to a modem hangup, nowadays usually because the user closed the terminal emulator window), a SIGHUP signal is sent to the controlling process running in that terminal — typically, the initial shell started in that terminal. Shells normally react to this by exiting. Before exiting, shells intended for interactive use send HUP to each job that they started.

Starting a job from a shell with nohup breaks that second source of HUP signals because the job will then ignore the signal and thus not be told to die when the terminal disappears. Other ways to break the propagation of HUP signals from the shell to the jobs include using the shell's disown builtin if it has one (the job is removed from the shell's list of jobs), and double forking (the shell launches a child which launches a child of its own and exits immediately; the shell has no knowledge of its grandchild).

Again, the jobs started in the terminal die not because their parent process (the shell) dies, but because their parent process decides to kill them when it is told to kill them. And the initial shell in the terminal dies not because its parent process dies, but because its terminal disappears (which may or may not coincidentally be because the terminal is provided by a terminal emulator which is the shell's parent process).

In the case of Linux, a task (kernel internal idea of a thread; threads can share resources, like memory and open files; some run only inside the kernel) can run in userland, or (it's thread of execution) can transfer into the kernel (and back) to execute a system call. A user thread can be highjacked temporarily to execute an interrupt (but that isn't really that thread running).

That a process is a "system process" or a regular user process is completely irrelevant in Unix, they are handled just the same. In Linux case, some tasks run in-kernel to handle miscellaneous jobs. They are kernel jobs, not "system processes" however.

One big caveat: Text books on complex software products (compilers and operating systems are particularly egregious examples) tend to explain simplistic algorithms (often ones that haven't been used in earnest for half a century), because real world machines and user requirements are much too complex to be handled in some way that can be described in a structured, simple way. Much of a compiler is ad-hoc tweaks (particularly in the area of code optimization, the transformations are mostly the subset of possibilities that show up in practical use). In the case of Linux, most of the code is device drivers (mentioned in passing as device-dependent in operating system texts), and of this code a hefty slice is handling misbehaving devices, which do not comply to their own specifications, or which behave differently between versions of "the same device". Often what is explained in minute detail is just the segment of the job that can be reduced to some nice theory, leaving the messy, irregular part (almost) completely out. For instance, Cris Fraser and David Hanson in their book describing the LCC compiler state that typical compiler texts contain mostly explanations on lexical analysis and parsing, and very little on code generation. Those tasks are some 5% of the code of their (engineered to be simple!) compiler, and had negligible error rate. The complex part of the compiler is just not covered in standard texts.