1

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 [snip] Attaching to process 11351 warning: process 11351 is a zombie - the process has already terminated ptrace: Operation not permitted. (gdb)

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 root serenity ~ #

For reference, my kernel version is 4.9.16-gentoo.

Improve this question
1
  • “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. Commented May 30, 2017 at 23:50

1 Answer 1

Reset to default
3

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 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 its exit status to be read.

Improve this answer
5
  • 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. Commented May 30, 2017 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. Commented May 30, 2017 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. Commented May 30, 2017 at 20:29
  • 1
    en.wikipedia.org/wiki/Zombie_process might be of help, the comment section is a little small :) Commented May 30, 2017 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. Commented May 30, 2017 at 20:32

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.