I'm just playing around with zombie processes on WSL. I wrote a quite simple program:
#include <stdio.h> #include <stdlib.h> #include <unistd.h> #define CHILD 0 int main(){ int p; p = fork(); if(p == CHILD){ printf("Kind-PID: %u\n", getpid()); exit(1); } else if(p > CHILD){ sleep(30); } else return EXIT_FAILURE; return EXIT_SUCCESS; } While I can see the zombie process on a native Linux using ps, I can't see a zombie process on WSL. Can anyone explain why?
Disclaimer: I know nothing about the internal workings of WSL. What I know about the details of the lifecycle of Windows processes is just a result of quick Googling. Feel free to correct me.
In Linux, the process state is tracked in Unix-style using its process table entry, which determines its PID number. As a consequence, when a process dies, the process table entry cannot be cleared until the (real or adopted) parent process has read the exit code of the dead process - keeping the PID number occupied. A process table entry that indicates the process is already died but the exit code has not yet been read is said to be in a zombie state. This state and various other bits of information in the process table are accessible to all processes in the system.
In Windows, process information is accessed by process handles. In addition, running processes also have a process ID. When a process dies, the PID number can be recycled immediately, as the exit code will be stored with the handle of the dead process, which is managed separately from the PID numbers. Unlike a PID number, a process handle will be valid until its holder closes it; the death of the process it refers to does not invalidate the process handle.
In order to faithfully display the equivalent of the "zombie" state in WSL, the WSL ps command would have to check the handles of all the other WSL processes to find the zombie processes, and then somehow get the PID numbers the processes used to have when they were alive - information that will not exist any more, unless the WSL subsystem specifically copied it from the Windows process table when the process was alive.
But process handles don't necessarily have to be public information: depending on how WSL is implemented, a WSL process might only be able to see the zombies of its own child processes, only zombies belonging to the same user, or maybe zombies of any WSL processes only. In order to reproduce the appearance of Unix-style zombie processes, WSL might have to keep a handle on each WSL process on the system.
But it's theoretically possible that the Windows PID of a dead WSL process gets recycled to another living process while the (real or adopted) parent of the dead WSL process takes its sweet time before reading the exit code of the dead process. What should WSL report as the PID of the zombie then? Reporting the PID that's already used by another living process is clearly a wrong thing to do; reporting a different PID for the zombie than it actually had when alive is not right either.
Since there is actually very little you can do with a zombie process, and the zombies are not cluttering up the PID number space, it might be a valid choice for WSL to not attempt to fully reproduce the concept of zombie processes at all for commands like ps.
