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]

2 Answers 2


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, 2016 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, 2016 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, 2021 at 22:06
  • @SimonRichter It's actually reparented to kthreadd. Dec 16, 2021 at 8:33
  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 and acknowledge that you have read and understand our privacy policy and code of conduct.

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