I have always learned that the init process is the ancestor of all processes. Why does process 2 have a PPID of 0?

$ ps -ef | head -n 3
root         1     0  0 May14 ?        00:00:01 /sbin/init
root         2     0  0 May14 ?        00:00:00 [kthreadd]

First, “ancestor” isn't the same thing as “parent”. The ancestor can be the parent's parent's … parent's parent, and the kernel only keeps track of one level. However, when a process dies, its children are adopted by init, so you will see a lot of processes whose parent is 1 on a typical system.

Modern Linux systems additionally have a few processes that execute kernel code, but are managed as user processes, as far as scheduling is concerned. (They don't obey the usual memory management rules since they're running kernel code.) These processes are all spawned by kthreadd (it's the init of kernel threads). You can recognize them by the fact that /proc/2/exe (normally a symbolic link to the process executable) can't be read. Also, ps lists them with a name between square brackets (which is possible for normal user processes, but unusual). Most processes whose parent process ID is 2 are kernel processes, but there are also a few kernel helper processes with PPID 2 (see below).

Processes 1 (init) and 2 (kthreadd) are created directly by the kernel at boot time, so they don't have a parent. The value 0 is used in their ppid field to indicate that. Think of 0 as meaning “the kernel itself” here.

Linux also has some facilities for the kernel to start user processes whose location is indicated via a sysctl parameter in certain circumstances. For example, the kernel can trigger module loading events (e.g. when new hardware is discovered, or when some network protocols are first used) by calling the program in the kernel.modprobe sysctl value. When a program dumps core, the kernel calls the program indicated by kernel.core_pattern if any. Those processes are user processes, but their parent is registered as kthreadd.

  • 3
    So init is the "ancestor" of all user threads, while [kthreadd ] is the "parent" of all kernel threads, right? Thx!
    – Nan Xiao
    May 16 '16 at 7:24
  • 2
    @NanXiao Mostly, yes. As I mention in my last paragraph, there are a few other ways for user processes to be started by the kernel, e.g. the program listed in kernel.core_pattern when a program dumps core. On a typical system you won't see them because those processes tend to do their job quickly and then exit. May 16 '16 at 11:41
  • Also, I'd expect the core dump tool to be reparented to init to avoid having to collect its exit code -- if a process with ppid 0 dies, the kernel panics. Dec 15 '21 at 22:06
  1. The task_struct of kernel is static generated by macro code.
    struct task_struct init_task = INIT_TASK(init_task);
    The nr is the global pid number. It starts from 0.
    #define INIT_STRUCT_PID {                                \
        .numbers     = { {                                   \
            .nr      = 0,                                    \
            .ns      = &init_pid_ns,                         \
            .pid_chain   = { .next = NULL, .pprev = NULL },  \
        }, }                                                 \
  2. Generate two threads in the process of booting the kernel: init, kthreadd.
    static noinline void __init_refok rest_init(void)
         /* spawn init thread */
         kernel_thread(kernel_init, NULL, CLONE_FS | CLONE_SIGHAND);
         /* spawn kthreadd thread */
         pid = kernel_thread(kthreadd, NULL, CLONE_FS | CLONE_FILES);
    The init process has pid 1 and kthreadd process has pid 2 as a natural consequence of being by the kernel. So their ppid is 0.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.