I looked into my zombie sh process a little further.
It's always got a parent process ID (PPID) of 5668
I looked up what that processcis using:
ps -F -p 5668
It tells me that process 5668 is /usr/bin/python/
The parent process of /usr/bin/python in turn is /sbin/init which as I understand is responsible for calling a whole bunch of startup scripts at boot.
I'm not sure how to proceed from this point. Should I kill the /usr/bin/python process every time I boot my computer? Will that impact other programs on my computer that are using Python?
Any ideas on how to further isolate why exactly Python is always leaving this zombie process?
Obviously, substitute the PID you got from the ps command for <pid> in the command above.Code:sudo grep -r <pid> /var/log
I'm not sure what happens in /proc when a process goes defunct. If you can cd into /proc/<pid>, you might be able to figure out something about the process from the various files in that directory.
1) "cat cmdline" should give you the name the process is running under (although this may just return "defunct" unfortunately)
2) "sudo cat environ | perl -pe 's/\000/\n/g'" gets you the environment variable settings for the process
3) "sudo ls -l fd" shows you what files the process currently has open
4) "sudo ls -l cwd" shows you the current working directory of the process
5) "sudo strings exe | less" will let you see the strings embedded in the executable (something like the "usage" message or help text embedded in the executable may tip you off about what the process is)
daemon.py is being run as "/usr/bin/python daemon.py", so techincally python is the parent. It's a known wicd issue, some process getting called by wicd to monitor network status isn't getting reaped properly. Every time the status is updated, the old zombie goes away and a new one appears (which is why the pid keeps changing). I haven't put a ton of time in figuring out which call is doing it, as I'm using a unreleased development version that doesn't run any subprocesses to monitor the network (so there are no zombies). If the bug still exists in the upcoming version (which still uses external program calls, but much fewer), I'll make some time to track down the problem call. If you want to test it out, you can check it out from our subversion repository. But really, the zombie is nothing to worry too much about, as someone said earlier, it takes up no memory and doesn't actually do anything. It just can't be cleared from the running process table because it's parent doesn't know it exited.