I have a reproducible situation where a compiler instance goes into a zombie state when I rebuild a package, but gdb won't permit me to attach:

serenity ~ # ps ax | grep defunct
11351 pts/1    Z+     0:00 [x86_64-pc-linux] <defunct>
21838 pts/5    S+     0:00 grep --colour=auto defunct
serenity ~ # gdb -p 11351
GNU gdb (Gentoo 7.10.1 vanilla) 7.10.1
Attaching to process 11351
warning: process 11351 is a zombie - the process has already terminated
ptrace: Operation not permitted.

This question suggests the problem is with proc.sys.kernel.yama.ptrace_scope, or that I might not be root, but that sysctl isn't present on my system, and I am running as root:

serenity ~ # sysctl -a | grep ptrace
sysctl: reading key "net.ipv6.conf.all.stable_secret"
sysctl: reading key "net.ipv6.conf.default.stable_secret"
sysctl: reading key "net.ipv6.conf.enp4s0.stable_secret"
sysctl: reading key "net.ipv6.conf.lo.stable_secret"
serenity ~ # whoami
serenity ~ # 

For reference, my kernel version is 4.9.16-gentoo.

  • “Zombie process” is a bit of a misnomer. A more accurate name would be “zombie of a process”, because a zombie isn't actually a process. – Gilles May 30 '17 at 23:50

As stated in your question output, a zombie process is one that has finished execution, so you'll never be able to attach to it using gdb - all it is now, I believe, is an entry in the kernel process table without any corresponding process or resources, so there is nothing for gdb to attach to.

The only reason this process table entry exists, marked as a zombie, is for it's exit status to be read.

  • So how would I get the stack for where it presently sits, even if that's in kernelspace? I can kill -9 it to make it go away, but I'd like to find and correct whatever leads it to the zombie state. – Michael Mol May 30 '17 at 20:25
  • 2
    There is no stack, just a bare struct within the kernel's process table that contains only one piece of useful info - the exit status code. As for debugging, you'll have to do that at any point before it exits. Finding out what the exit code is would be a good start. – einonm May 30 '17 at 20:26
  • Then why is it still there? The only times I've seen zombie states in the past were when a process was killed during a hung syscall, such as writes to faulty I/O devices, but I have no evidence of that being the case here. – Michael Mol May 30 '17 at 20:29
  • 1
    en.wikipedia.org/wiki/Zombie_process might be of help, the comment section is a little small :) – einonm May 30 '17 at 20:31
  • 2
    It's still there because its parent hasn't waited for it. It's worth debugging the parent to see what it's doing. Often the reason is that the parent got a SIGTSTP or some other signal that suspended it. – Mark Plotnick May 30 '17 at 20:32

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.