Btukfyl

When I used killall -9 name to kill a program, the state become zombie. Some minutes later, it stopped really.
So, what's happening during those minutes?

The program actually never receives the SIGKILL signal, as SIGKILL is completely handled by the operating system/kernel.

When SIGKILL for a specific process is sent, the kernel's scheduler immediately stops giving that process any more CPU time (and interrupts its currently executing threads, if there is any). As a result, the process itself would never get the chance to actually process the information that it has received a SIGKILL. Then other kernel routines are called to remove the process from memory and free all resources it had open at the time. As usual, the parent (PPID) of the killed process is notified of the death of the child process with a SIGCHLD signal.

When a process is in a "zombie" state it means the process is already dead, but its parent process has not yet acknowledged this by reading the exit code of the dead process using the wait(2) system call. Basically the only resource a zombie process is consuming any more is a slot in the process table that holds its PID, the exit code and some other "vital statistics" of the process at the time of its death.

If the parent process dies before its children, the orphaned child processes are automatically adopted by PID #1, which has a special duty to keep calling wait(2) so that any orphaned processes won't stick around as zombies.

If it takes several minutes for a zombie process to clear, it suggests that the parent process of the zombie is struggling or not doing its job properly.

There is a tongue-in-cheek description on what to do in case of zombie problems in Unix-like operating systems: "You cannot do anything for the zombies themselves, as they are already dead. Instead, kill the evil zombie master!" (i.e. the parent process of the troublesome zombies)