2002 2003 2004 2005 2006 2007 <2008> 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 | Index | 2002 2003 2004 2005 2006 2007 <2008> 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: zombies |
From: | Andrew Johnson <[email protected]> |
To: | Artem Kazakov <[email protected]> |
Cc: | EPICS core-talk <[email protected]> |
Date: | Fri, 23 May 2008 14:49:12 -0500 |
Hi Artem, Artem Kazakov wrote:
I recall that you've showed me that on some of the machines my ruby script was waiting for the output from the caputackt command, while the latter being zombie. So yesterday encountered the same behavior on my Mac-box. And the funny thing is that if I start caRepeater as separate independent process, everything works as supposed. But if the caRepeater is not running, then it is started somewhere from ca library (I guess?) and then there is a zombie walking around and caRepeater process is still running. If I kill that spawned caRepeater process by hand, than zombie finally dies and script continues until next caLib using command (such as caput) and then again there is a zombie and caRepeater. Is it supposed to be like that ? I'm not so familiar with the ca lib internals and caRepeater interaction, but may be you can get give me a hint on what's going on?
If there is no caRepeater running on the machine, a CA client program will start one when it initializes the CA library. The preferred method is to fork() and execlp() the external caRepeater program, but if it can't find caRepeater in $PATH the child process will print a warning and run the repeater functionality itself. Do you have a copy of caRepeater in your $PATH? I suspect not, and that if you did you'd find the zombie would not appear — please confirm that if possible.
What are the parent processes of the caRepeater and of the zombie?However just copying caRepeater into your $PATH won't resolve the fundamental issue that somehow it's generating zombies. I'm not sure how, but it obviously can. I double-checked the src/libCom/osi/os/posix code that makes the fork()/execlp() calls; it is not getting the child and parent processes mixed up.
- Andrew -- Talk is cheap. Show me the code. -- Linus Torvalds