RE: problems in Perl process management
Hi - Asking again since I didn't get a response... demonstrated by my testcase script), the CW_GETPINFO_FULL query returns: 1. Invalid PPIDs Only PPIDs for cygwin processes are returned. Everything else should be 0. Both Proc::ProcessTable and 'ps -W' use CW_GETPINFO_FULL. My Perl testcase * forks and runs '/bin/sleep' with the Perl backtick operator. Proc::ProcessTable and 'ps -W' then report the following about the testcase processes: 1. PID and PPID of the fork-ed Perl processes -- reported normally. 2. PID and PPID of the 'sleep' process -- reported as if it was a non-Cygwin process. i.e. PID=WINPID, PPID=0. But the 'sleep' process is a Cygwin process, right? Does this indicate a bug in CW_GETPINFO_FULL? Regards, Sonam Chauhan -- Electronic Commerce, Corporate Express Australia Ltd. Phone: +61-2-9335-0725, Email: [EMAIL PROTECTED] * Testcase attached to bug report filed here: http://rt.cpan.org/NoAuth/Bug.html?id=12840 -Original Message- From: Sonam Chauhan Sent: Wednesday, 18 May 2005 3:32 PM To: 'cygwin@cygwin.com' Subject: RE: problems in Perl process management Thanks for raising 'ps -W' behavior Chris. It is interesting. From what I gather, the root problem is that for some processes (as demonstrated by my testcase script), the CW_GETPINFO_FULL query returns: 1. Invalid PPIDs Only PPIDs for cygwin processes are returned. Everything else should be 0. This isn't happening in my testcase - a Perl script that forks, then executes `/bin/sleep` with a Perl backtick. Proc::ProcessTable (i.e. CW_GETPINFO_FULL) returns invalid PPID (0) and PID (the WINPID) for the child sleep process, but it does returns correct PID and PPID data for the fork-ed Perl parent processes. The PID/PPID of the backticked sleep process shows up correctly in 'ps'. Would this be an issue within CW_GETPINFO_FULL? 2. WINPID instead of Cygwin PID. A cygwin pid can actually be spread across two processes. You see this with ps -W if you do something like: bash -c exec sleep 20 in one window and: ps -W in another window. I tried this but don't see what you mean. Here, in one window, I do: === $ bash -c exec sleep 20 === In the second window, 'ps -W' only reports the PID PPID for a single sleep process: === $ ps -W | grep sleep 1012 0 0 1012?0 14:57:51 C:\cygwin\bin\sleep.exe === However, instead of sleep, if I run a windows program like calc.exe in the background, ps -W reports two processes: Was this what you meant about the cygwin pid being spread across two processes? === $ calc [1] 2380 $ ps -W | grep calc 238037802380 36040 400 15:18:21 /cygdrive/c/WINDOWS/system32/calc 3604 0 0 3604?0 15:18:22 c:\WINDOWS\system32\calc.exe === Regards, Sonam Chauhan -- Electronic Commerce, Corporate Express Australia Ltd. Phone: +61-2-9335-0725, Email: [EMAIL PROTECTED] cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: problems in Perl process management
On Tue, May 24, 2005 at 05:11:00PM +1000, Sonam Chauhan wrote: Hi - Asking again since I didn't get a response... You got a response before you asked the question. demonstrated by my testcase script), the CW_GETPINFO_FULL query returns: 1. Invalid PPIDs Only PPIDs for cygwin processes are returned. Everything else should be 0. Both Proc::ProcessTable and 'ps -W' use CW_GETPINFO_FULL. My Perl testcase * forks and runs '/bin/sleep' with the Perl backtick operator. Proc::ProcessTable and 'ps -W' then report the following about the testcase processes: 1. PID and PPID of the fork-ed Perl processes -- reported normally. 2. PID and PPID of the 'sleep' process -- reported as if it was a non-Cygwin process. i.e. PID=WINPID, PPID=0. But the 'sleep' process is a Cygwin process, right? Does this indicate a bug in CW_GETPINFO_FULL? Almost a week ago, I wrote: On Tue, May 17, 2005 at 11:08:29PM -0400, Christopher Faylor wrote: ps -W will also not always properly report on execed processes in ^ general. Since ps -W uses CW_GETPINFO_FULL, you can use that command to see what is going on. i.e., you can't use CW_GETPINFO_FULL to do what you seem to be expecting to do. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: problems in Perl process management
Please clarify so I understand better. Are you saying that since... ps -W will also not always properly report on execed processes in ^ general. Since ps -W uses CW_GETPINFO_FULL, ... ... by implication, CW_GETPINFO_FULL does not report on execed processes properly. If this is the case, isn't this a bug in CW_GETPINFO_FULL? Won't it be better fixing this bug, than fixing 'Proc::ProcessTable' and 'ps -W' and all the other programs that uses CW_GETPINFO_FULL? Sonam Chauhan -- Electronic Commerce, Corporate Express Australia Ltd. Phone: +61-2-9335-0725, Email: [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: problems in Perl process management
On Wed, May 25, 2005 at 09:45:50AM +1000, Sonam Chauhan wrote: Please clarify so I understand better. Are you saying that since... ps -W will also not always properly report on execed processes in ^ general. Since ps -W uses CW_GETPINFO_FULL, ... ... by implication, CW_GETPINFO_FULL does not report on execed processes properly. Now you're getting it. If this is the case, isn't this a bug in CW_GETPINFO_FULL? Won't it be better fixing this bug, than fixing 'Proc::ProcessTable' and 'ps -W' and all the other programs that uses CW_GETPINFO_FULL? There is no reference implementation which would specify that the behavior which I noted was incorrect. CW_GETPINFO_FULL was implemented for ps -W. I don't believe I've ever heard anyone complaining about the way this works in ps -W or in all of the other programs which use this. If you want to submit a patch which changes this behavior, I'll certainly review it promptly. I don't believe that it would be trivial to do, however. It seems to me that it would be a lot easier to work around in the perl module. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: problems in Perl process management
Chris: ps -W will also not always properly report on execed processes in ^ general. Since ps -W uses CW_GETPINFO_FULL, ... Won't it be better fixing this bug, than fixing 'Proc::ProcessTable' and 'ps -W' and all the other programs that uses CW_GETPINFO_FULL? There is no reference implementation which would specify that the behavior which I noted was incorrect. CW_GETPINFO_FULL was implemented for ps -W. So the accurate-reporting-except-for-execed-processes behavior is canonical in CW_GETPINFO_FULL as of now. I'd suggest noting this in the man page for 'ps -W' so people know it's true behavior. Right now, all it says is: -W, --windows show windows as well as cygwin processes ... The -W option causes ps show non-Cygwin Windows processes as well as Cygwin processes I don't believe I've ever heard anyone complaining about the way this works in ps -W or in all of the other programs which use this. There's a first time for everything. If you want to submit a patch which changes this behavior, I'll certainly review it promptly. I don't believe that it would be trivial to do, however. I'm not skilled enough, so I'll leave that alone. It seems to me that it would be a lot easier to work around in the perl module. Can you suggest any other CW_... query that would report on PIDs accurately? Regards, Sonam -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: problems in Perl process management
On Wed, May 25, 2005 at 02:41:28PM +1000, Sonam Chauhan wrote: cgf wrote: I don't believe I've ever heard anyone complaining about the way this works in ps -W or in all of the other programs which use this. There's a first time for everything. I guess I'll wait for the second, third, and fourth time for everything before I start getting really worried. It seems to me that it would be a lot easier to work around in the perl module. Can you suggest any other CW_... query that would report on PIDs accurately? CW_GETPINFO reports on PIDs accurately, AFAIK. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: problems in Perl process management
I guess I'll wait for the second, third, and fourth time for everything before I start getting really worried. As you like. It seems to me that it would be a lot easier to work around in the perl module. Can you suggest any other CW_... query that would report on PIDs accurately? CW_GETPINFO reports on PIDs accurately, AFAIK. Thanks. Cheers, Sonam Chauhan -- Electronic Commerce, Corporate Express Australia Ltd. Phone: +61-2-9335-0725, Email: [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: problems in Perl process management
Yitzchak: sorry this reply is late. I just reread the whole thread three times, and fail to detect any rudeness from him. He did confess to being flip, though. (I thought it was just an attempt at humor.) http://dictionary.reference.com/search?q=flip I also notice that deeper forked processes (grandchildren) refuse to die. ... You can't send cygwin (aka unix) signals to a windows proram. Which is wrong - we were talking about killing the Cygwin PID. we? He wasn't responding to you, and I see nothing in Jurgen's message to indicate he is talking about a situation involving *any* cygwin programs; in fact, quite the contrary. By we, I meant Jurgen and me. I just reread that thread and there has been a bit of confusion. My problem is in killing certain Cygwin processes with Cygwin Perl's built-in kill. Jurgen reply was about problems killing ActivePerl processes (run by Cygwin) with ActivePerl's built-in kill: http://aspn.activestate.com/ASPN/docs/ActivePerl/lib/Pod/perlfork.html#item_ kill ActivePerl's kill wouldn't use signals at all, so that part of the discussion went the wrong way. Sorry for the confusion from my side. In another email you said: As I understand it, kill -9 does not send a signal, and certainly not to a windows program. That's interesting. SIGKILL can't be trapped by any program, but why would 'kill -9' not send a SIGKILL for a Cygwin process? Regards, Sonam Chauhan -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: problems in Perl process management
Sonam Chauhan schrieb: Reini - Thanks for replying man. I didn't complain yet upstream at rt.cpan.org because I wanted to wait for our 5.8.7 release. But you can do it by yourself also, OK, I'm not that talented, so I didn't try fixing this bug, but I did report it with a better testcase here: http://rt.cpan.org/NoAuth/Bug.html?id=12840 or fix it in this module XS. It's really easy with the cygwin provided translation functions. See http://sourceware.org/ml/cygwin/2005-02/msg00154.html I had a look at your post, but out of curiosity, isn't it about adding functionality for looking up the WINPID from the Cygwin process ID? Is the fix really that simple? Yes, that simple. After all, Proc::ProcessTable misreports the PID and PPID only under certain conditions -- this would indicate a complex issue in Proc::ProcessTable XS code, right? No. Just the translation is needed, but one has to specify somehow which pid's he wants. The cygwin pid's or the winpid's. Both have their merits and usecases. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ http://phpwiki.org/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: problems in Perl process management
Reini: [Note, I'm no Cygwin expert, so please correct any misunderstandings.] or fix it in this module XS. It's really easy with the cygwin provided translation functions. See http://sourceware.org/ml/cygwin/2005-02/msg00154.html ... After all, Proc::ProcessTable misreports the PID and PPID only under certain conditions -- this would indicate a complex issue in Proc::ProcessTable XS code, right? No. Just the translation is needed, but one has to specify somehow which pid's he wants. The cygwin pid's or the winpid's. Both have their merits and usecases. Why are two usecases needed? The code that builds the process table (returned by Proc::ProcessTable-table) should return the same PID and PPID that 'ps' reports - no exceptions - right? I had a look in Proc::ProcessTable's .xs and os/cygwin.c. There seem to be a problem with the process table data returned by this code in the OS_get_table() function: This defines an internal Cygwin query to return process information: cygwin_getinfo_types query = CW_GETPINFO_FULL; This executes the query within a for loop: p = (external_pinfo *) cygwin_internal (query, pid | CW_NEXTPID); From what I gather, the root problem is that for some processes (as demonstrated by my testcase script), the CW_GETPINFO_FULL query returns: 1. Invalid PPIDs 2. WINPID instead of Cygwin PID. How will the translation functions you mentioned solve these two problems? Cheers, Sonam -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: problems in Perl process management
On Wed, May 18, 2005 at 01:01:48PM +1000, Sonam Chauhan wrote: Reini: [Note, I'm no Cygwin expert, so please correct any misunderstandings.] or fix it in this module XS. It's really easy with the cygwin provided translation functions. See http://sourceware.org/ml/cygwin/2005-02/msg00154.html ... After all, Proc::ProcessTable misreports the PID and PPID only under certain conditions -- this would indicate a complex issue in Proc::ProcessTable XS code, right? No. Just the translation is needed, but one has to specify somehow which pid's he wants. The cygwin pid's or the winpid's. Both have their merits and usecases. Why are two usecases needed? The code that builds the process table (returned by Proc::ProcessTable-table) should return the same PID and PPID that 'ps' reports - no exceptions - right? I had a look in Proc::ProcessTable's .xs and os/cygwin.c. There seem to be a problem with the process table data returned by this code in the OS_get_table() function: This defines an internal Cygwin query to return process information: cygwin_getinfo_types query = CW_GETPINFO_FULL; This executes the query within a for loop: p = (external_pinfo *) cygwin_internal (query, pid | CW_NEXTPID); From what I gather, the root problem is that for some processes (as demonstrated by my testcase script), the CW_GETPINFO_FULL query returns: 1. Invalid PPIDs Only PPIDs for cygwin processes are returned. Everything else should be 0. Orphaned cygwin processes or processes started from the command line have a PPID of 1. 2. WINPID instead of Cygwin PID. A cygwin pid can actually be spread across two processes. You see this with ps -W if you do something like: bash -c exec sleep 20 in one window and: ps -W in another window. ps -W will also not always properly report on execed processes in general. Since ps -W uses CW_GETPINFO_FULL, you can use that command to see what is going on. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: problems in Perl process management
Thanks for raising 'ps -W' behavior Chris. It is interesting. From what I gather, the root problem is that for some processes (as demonstrated by my testcase script), the CW_GETPINFO_FULL query returns: 1. Invalid PPIDs Only PPIDs for cygwin processes are returned. Everything else should be 0. This isn't happening in my testcase - a Perl script that forks, then executes `/bin/sleep` with a Perl backtick. Proc::ProcessTable (i.e. CW_GETPINFO_FULL) returns invalid PPID (0) and PID (the WINPID) for the child sleep process, but it does returns correct PID and PPID data for the fork-ed Perl parent processes. The PID/PPID of the backticked sleep process shows up correctly in 'ps'. Would this be an issue within CW_GETPINFO_FULL? 2. WINPID instead of Cygwin PID. A cygwin pid can actually be spread across two processes. You see this with ps -W if you do something like: bash -c exec sleep 20 in one window and: ps -W in another window. I tried this but don't see what you mean. Here, in one window, I do: === $ bash -c exec sleep 20 === In the second window, 'ps -W' only reports the PID PPID for a single sleep process: === $ ps -W | grep sleep 1012 0 0 1012?0 14:57:51 C:\cygwin\bin\sleep.exe === However, instead of sleep, if I run a windows program like calc.exe in the background, ps -W reports two processes: Was this what you meant about the cygwin pid being spread across two processes? === $ calc [1] 2380 $ ps -W | grep calc 238037802380 36040 400 15:18:21 /cygdrive/c/WINDOWS/system32/calc 3604 0 0 3604?0 15:18:22 c:\WINDOWS\system32\calc.exe === Regards, Sonam Chauhan -- Electronic Commerce, Corporate Express Australia Ltd. Phone: +61-2-9335-0725, Email: [EMAIL PROTECTED] cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: problems in Perl process management
Reini - Thanks for replying man. I didn't complain yet upstream at rt.cpan.org because I wanted to wait for our 5.8.7 release. But you can do it by yourself also, OK, I'm not that talented, so I didn't try fixing this bug, but I did report it with a better testcase here: http://rt.cpan.org/NoAuth/Bug.html?id=12840 or fix it in this module XS. It's really easy with the cygwin provided translation functions. See http://sourceware.org/ml/cygwin/2005-02/msg00154.html I had a look at your post, but out of curiosity, isn't it about adding functionality for looking up the WINPID from the Cygwin process ID? Is the fix really that simple? After all, Proc::ProcessTable misreports the PID and PPID only under certain conditions -- this would indicate a complex issue in Proc::ProcessTable XS code, right? Regards, Sonam Chauhan -- Electronic Commerce, Corporate Express Australia Ltd. Phone: +61-2-9335-0725, Email: [EMAIL PROTECTED] -Original Message- From: Reini Urban [mailto:[EMAIL PROTECTED] Sent: Sunday, 15 May 2005 2:32 AM To: 'cygwin@cygwin.com' Cc: Sonam Chauhan Subject: Re: problems in Perl process management Sonam Chauhan schrieb: I had thought Gerrit would release a new 5.8.6 with them, but this doesn't seem to have happened; don't know if I somehow dropped the ball on that. In any case, I'm really really hoping that 5.8.7 is released in the next few weeks. I don't know anything about problems with Proc::ProcessTable other than what may have been mentioned in that thread. Perhaps you'd like to look into it further? Yes. Can you confirm whether your patch addresses a problem Reini reported your thread in Feb? It was this message: http://sourceware.org/ml/cygwin/2005-02/msg00224.html ...where Reini said: But the cygwin pid's seem to be wrong. Some cygwin processes are not detected as such, so the pids are listed as winpid's. And fname is printed as windows path for those processes, though it should be printed as cygwin path. I'll complain upstream. Sorry for being late. I'm catching up old email. I didn't complain yet upstream at rt.cpan.org because I wanted to wait for our 5.8.7 release. But you can do it by yourself also, or fix it in this module XS. It's really easy with the cygwin provided translation functions. See http://sourceware.org/ml/cygwin/2005-02/msg00154.html My problem is similar - in Cygwin, Proc::ProcessTable reports some PIDs as WINPIDs instead of Cygwin PIDs. In terms of my testcase (attached to my first email), the effect is that the get_pids method in Proc::Killfam.pm does not recurse down all descendant processes due to inaccurate PID reporting by Proc::ProcessTable. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ http://phpwiki.org/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: problems in Perl process management
Sonam Chauhan schrieb: I had thought Gerrit would release a new 5.8.6 with them, but this doesn't seem to have happened; don't know if I somehow dropped the ball on that. In any case, I'm really really hoping that 5.8.7 is released in the next few weeks. I don't know anything about problems with Proc::ProcessTable other than what may have been mentioned in that thread. Perhaps you'd like to look into it further? Yes. Can you confirm whether your patch addresses a problem Reini reported your thread in Feb? It was this message: http://sourceware.org/ml/cygwin/2005-02/msg00224.html ...where Reini said: But the cygwin pid's seem to be wrong. Some cygwin processes are not detected as such, so the pids are listed as winpid's. And fname is printed as windows path for those processes, though it should be printed as cygwin path. I'll complain upstream. Sorry for being late. I'm catching up old email. I didn't complain yet upstream at rt.cpan.org because I wanted to wait for our 5.8.7 release. But you can do it by yourself also, or fix it in this module XS. It's really easy with the cygwin provided translation functions. See http://sourceware.org/ml/cygwin/2005-02/msg00154.html My problem is similar - in Cygwin, Proc::ProcessTable reports some PIDs as WINPIDs instead of Cygwin PIDs. In terms of my testcase (attached to my first email), the effect is that the get_pids method in Proc::Killfam.pm does not recurse down all descendant processes due to inaccurate PID reporting by Proc::ProcessTable. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ http://phpwiki.org/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: problems in Perl process management
Yitzchak: I had thought Gerrit would release a new 5.8.6 with them, but this doesn't seem to have happened; don't know if I somehow dropped the ball on that. In any case, I'm really really hoping that 5.8.7 is released in the next few weeks. I don't know anything about problems with Proc::ProcessTable other than what may have been mentioned in that thread. Perhaps you'd like to look into it further? Yes. Can you confirm whether your patch addresses a problem Reini reported your thread in Feb? It was this message: http://sourceware.org/ml/cygwin/2005-02/msg00224.html ...where Reini said: But the cygwin pid's seem to be wrong. Some cygwin processes are not detected as such, so the pids are listed as winpid's. And fname is printed as windows path for those processes, though it should be printed as cygwin path. I'll complain upstream. My problem is similar - in Cygwin, Proc::ProcessTable reports some PIDs as WINPIDs instead of Cygwin PIDs. In terms of my testcase (attached to my first email), the effect is that the get_pids method in Proc::Killfam.pm does not recurse down all descendant processes due to inaccurate PID reporting by Proc::ProcessTable. ActiveState perl is a windows program. You can't send cygwin (aka unix) signals to a windows proram. This should be possible if the ActiPerl Windows executable was executed from a Cygwin terminal -- 'ps' shows it running and 'kill -9' should kill it. ? This should be possible meaning what? You indeed can't send cygwin signals (which AIUIkill -9 is not) to windows programs. What is 'AIUIkill'? Did you mean 'kill -9'? Isn't SIGKILL a Unix signal? The context of the original discussion was about killing processes by sending a SIGKILL (please see: http://sourceware.org/ml/cygwin/2005-05/msg00550.html ) Sincerely, Sonam Chauhan -- Electronic Commerce, Corporate Express Australia Ltd. Phone: +61-2-9335-0725, Email: [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: problems in Perl process management
On Fri, May 13, 2005 at 07:11:23PM +1000, Sonam Chauhan wrote: Can you confirm whether your patch addresses a problem Reini reported your thread in Feb? It was this message: http://sourceware.org/ml/cygwin/2005-02/msg00224.html ...where Reini said: But the cygwin pid's seem to be wrong. Some cygwin processes are not detected as such, so the pids are listed as winpid's. And fname is printed as windows path for those processes, though it should be printed as cygwin path. I'll complain upstream. My problem is similar - in Cygwin, Proc::ProcessTable reports some PIDs as WINPIDs instead of Cygwin PIDs. No, my patch does nothing for Proc::ProcessTable; it just provides access to the pid conversion functions from perl. In terms of my testcase (attached to my first email), the effect is that the get_pids method in Proc::Killfam.pm does not recurse down all descendant processes due to inaccurate PID reporting by Proc::ProcessTable. ActiveState perl is a windows program. You can't send cygwin (aka unix) signals to a windows proram. This should be possible if the ActiPerl Windows executable was executed from a Cygwin terminal -- 'ps' shows it running and 'kill -9' should kill it. ? This should be possible meaning what? You indeed can't send cygwin signals (which AIUIkill -9 is not) to windows programs. What is 'AIUIkill'? Did you mean 'kill -9'? Isn't SIGKILL a Unix signal? The context of the original discussion was about killing processes by sending a SIGKILL (please see: http://sourceware.org/ml/cygwin/2005-05/msg00550.html ) There was supposed to be a space after AIUI (as I understand it). As I understand it, kill -9 does not send a signal, and certainly not to a windows program. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: problems in Perl process management
Earlier topquoting somewhat reformated. On Thu, May 12, 2005 at 10:09:18AM +1000, Sonam Chauhan wrote: On Wed, May 11, 2005 at 04:24:56PM +1000, Sonam Chauhan wrote: Christopher - Yes, if you send a kill -9 to a pid that shows up in ps but is associated with a non-cygwin process, it should work. So what me and Jurgen were discussing works, and you were wrong. Thanks for revisiting your point after your earlier rudeness. I just reread the whole thread three times, and fail to detect any rudeness from him. He did confess to being flip, though. (I thought it was just an attempt at humor.) YJS? I don't understand this. Me neither, nor http://cygwin.com/acronyms or the other sites linked to there. I felt the need to clarify after your observation about kill -9 which mentioned a cygwin terminal and did not appear to have any direct The Perl testcase in my first email showed I was calling killfam 'KILL', $childpid. Jurgen replied he also wanted to know if this was possible and reported a similar problem killing grandchildren processes in Perl (but with Perl's built-in kill command). At this point, you entered the conversation and told him: I also notice that deeper forked processes (grandchildren) refuse to die. ... You can't send cygwin (aka unix) signals to a windows proram. Which is wrong - we were talking about killing the Cygwin PID. we? He wasn't responding to you, and I see nothing in Jurgen's message to indicate he is talking about a situation involving *any* cygwin programs; in fact, quite the contrary. When I corrected you, thinking that maybe you were talking about non-Cygwin Windows programs, your initial reply was this one-liner: This should be possible if the ActiPerl Windows executable was executed from a Cygwin terminal -- 'ps' shows it running and should kill 'kill -9' it. I guess I forgot my signature. ... Cygwin Co-Project Leader Which isn't any help. You later corrected yourself. Since I didn't recognize your name, and you seemed to be trying to inform me about code that I wrote, No. As mentioned in my *first* email, the problem is probably Perl's Proc::ProcessTable module. Unless you wrote the Perl XS interface for Proc::ProcessTable (or something similar that controls it's behavior), this does not concern your code which probably behaves just fine. Coming back to actual issue I referenced a discussion earlier on this list where a similar problem was discussed. I was hoping to hear from the people originally discussing it (Reini, Yitzchak, etc.) If you can help with this issue - great. Regards, Sonam Chauhan -- Electronic Commerce, Corporate Express Australia Ltd. Phone: +61-2-9335-0725, Email: [EMAIL PROTECTED] -Original Message- From: Christopher Faylor [mailto:[EMAIL PROTECTED] Sent: Thursday, 12 May 2005 1:18 AM To: cygwin@cygwin.com Subject: Re: problems in Perl process management YJS? I felt the need to clarify after your observation about kill -9 which mentioned a cygwin terminal and did not appear to have any direct bearing on the statement However, I also notice that deeper forked processes (grandchildren) refuse to die. This script is only run using ActiveState Perl. If someone is talking about fork on windows in a cygwin mailing list then they must be talking about starting processes using cygwin so mentioning a cygwin terminal doesn't make a lot of sense in that context. You don't need to start processes from bash for them to be able to receive signals. If they are saying that they are unable to kill processes then, my previous (unstated) assumption that they are using winpids rather than cygwin pids seems likely. Either that or they are using SIGTERM and the signal is blocked, in which case your kill -9 would work. I don't know why something which expects to be killed via SIGTERM would block SIGTERM but I guess it is a possibility. Since I didn't recognize your name, and you seemed to be trying to inform me about code that I wrote, I included my signature in the message to clarify. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: problems in Perl process management
On Fri, May 13, 2005 at 05:53:07AM -0700, Yitzchak Scott-Thoennes wrote: Earlier topquoting somewhat reformated. Apologies for not trimming the tail end of that (including email addresses). -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: problems in Perl process management
On Wed, May 11, 2005 at 11:18:16AM -0400, Christopher Faylor wrote: bearing on the statement However, I also notice that deeper forked processes (grandchildren) refuse to die. This script is only run using ActiveState Perl. If someone is talking about fork on windows in a cygwin mailing list then they must be talking about starting processes using cygwin so mentioning a cygwin terminal doesn't make a lot of sense in that context. You don't need to start processes from bash for them to be able to receive signals. FWIW, win32 perl does emulate fork with threads (and mass copying of all the perl code and data). Missed the start of this thread, so don't know how likely/unlikely that is to be the problem situation. If they are saying that they are unable to kill processes then, my previous (unstated) assumption that they are using winpids rather than cygwin pids seems likely. Either that or they are using SIGTERM and the signal is blocked, in which case your kill -9 would work. I don't know why something which expects to be killed via SIGTERM would block SIGTERM but I guess it is a possibility. Since I didn't recognize your name, and you seemed to be trying to inform me about code that I wrote, I included my signature in the message to clarify. I, for one, understood your clarification in the signature message :) -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: problems in Perl process management
Christopher - Yes, if you send a kill -9 to a pid that shows up in ps but is associated with a non-cygwin process, it should work. So what me and Jurgen were discussing works, and you were wrong. Thanks for revisiting your point after your earlier rudeness. Regards, Sonam Chauhan -- Electronic Commerce, Corporate Express Australia Ltd. Phone: +61-2-9335-0725, Email: [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: problems in Perl process management
On Wed, May 11, 2005 at 04:24:56PM +1000, Sonam Chauhan wrote: Christopher - Yes, if you send a kill -9 to a pid that shows up in ps but is associated with a non-cygwin process, it should work. So what me and Jurgen were discussing works, and you were wrong. Thanks for revisiting your point after your earlier rudeness. YJS? I felt the need to clarify after your observation about kill -9 which mentioned a cygwin terminal and did not appear to have any direct bearing on the statement However, I also notice that deeper forked processes (grandchildren) refuse to die. This script is only run using ActiveState Perl. If someone is talking about fork on windows in a cygwin mailing list then they must be talking about starting processes using cygwin so mentioning a cygwin terminal doesn't make a lot of sense in that context. You don't need to start processes from bash for them to be able to receive signals. If they are saying that they are unable to kill processes then, my previous (unstated) assumption that they are using winpids rather than cygwin pids seems likely. Either that or they are using SIGTERM and the signal is blocked, in which case your kill -9 would work. I don't know why something which expects to be killed via SIGTERM would block SIGTERM but I guess it is a possibility. Since I didn't recognize your name, and you seemed to be trying to inform me about code that I wrote, I included my signature in the message to clarify. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: problems in Perl process management
Chris - YJS? I don't understand this. I felt the need to clarify after your observation about kill -9 which mentioned a cygwin terminal and did not appear to have any direct The Perl testcase in my first email showed I was calling killfam 'KILL', $childpid. Jurgen replied he also wanted to know if this was possible and reported a similar problem killing grandchildren processes in Perl (but with Perl's built-in kill command). At this point, you entered the conversation and told him: I also notice that deeper forked processes (grandchildren) refuse to die. ... You can't send cygwin (aka unix) signals to a windows proram. Which is wrong - we were talking about killing the Cygwin PID. When I corrected you, thinking that maybe you were talking about non-Cygwin Windows programs, your initial reply was this one-liner: This should be possible if the ActiPerl Windows executable was executed from a Cygwin terminal -- 'ps' shows it running and should kill 'kill -9' it. I guess I forgot my signature. ... Cygwin Co-Project Leader Which isn't any help. You later corrected yourself. Since I didn't recognize your name, and you seemed to be trying to inform me about code that I wrote, No. As mentioned in my *first* email, the problem is probably Perl's Proc::ProcessTable module. Unless you wrote the Perl XS interface for Proc::ProcessTable (or something similar that controls it's behavior), this does not concern your code which probably behaves just fine. Coming back to actual issue I referenced a discussion earlier on this list where a similar problem was discussed. I was hoping to hear from the people originally discussing it (Reini, Yitzchak, etc.) If you can help with this issue - great. Regards, Sonam Chauhan -- Electronic Commerce, Corporate Express Australia Ltd. Phone: +61-2-9335-0725, Email: [EMAIL PROTECTED] -Original Message- From: Christopher Faylor [mailto:[EMAIL PROTECTED] Sent: Thursday, 12 May 2005 1:18 AM To: cygwin@cygwin.com Subject: Re: problems in Perl process management On Wed, May 11, 2005 at 04:24:56PM +1000, Sonam Chauhan wrote: Christopher - Yes, if you send a kill -9 to a pid that shows up in ps but is associated with a non-cygwin process, it should work. So what me and Jurgen were discussing works, and you were wrong. Thanks for revisiting your point after your earlier rudeness. YJS? I felt the need to clarify after your observation about kill -9 which mentioned a cygwin terminal and did not appear to have any direct bearing on the statement However, I also notice that deeper forked processes (grandchildren) refuse to die. This script is only run using ActiveState Perl. If someone is talking about fork on windows in a cygwin mailing list then they must be talking about starting processes using cygwin so mentioning a cygwin terminal doesn't make a lot of sense in that context. You don't need to start processes from bash for them to be able to receive signals. If they are saying that they are unable to kill processes then, my previous (unstated) assumption that they are using winpids rather than cygwin pids seems likely. Either that or they are using SIGTERM and the signal is blocked, in which case your kill -9 would work. I don't know why something which expects to be killed via SIGTERM would block SIGTERM but I guess it is a possibility. Since I didn't recognize your name, and you seemed to be trying to inform me about code that I wrote, I included my signature in the message to clarify. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: problems in Perl process management
I also would like to know if it is possible. However, it could be that it has nothing to do with Cygwin. I have a Perl script which forks several children and monitors their output. If a child fails, then it has no use to run all forked processes further and I kill them with the perl 'kill' command. However, I also notice that deeper forked processes (grandchildren) refuse to die. This script is only run using ActiveState Perl. I think it is really a serious Windows problem, because using the task manager it also seems not really possible to kill a complete process hierarchy. Regards, Jurgen Defurne Sonam Chauhan [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 2005-05-10 10:41 AM To: 'cygwin@cygwin.com' cygwin@cygwin.com cc: (bcc: Jurgen Defurne/BRG/CE/PHILIPS) Subject:problems in Perl process management Classification: Hello - I'd appreciate help with problems doing process management in Cygwin/Perl. I have a Perl application that creates child processes - I need it to kill processes that exceed a certain timeout. I am trying to use the Proc::ProcessTable and Proc::Killfam CPAN modules for this. I ran into two problems: The first problem was a can't stat /dev error message produced when calling Proc::Killfam. This problem was fixed by a script I found that populated entries under /dev. To understand the next probem, have a look at the simple test script attached. The script forks a child process, which runs `sleep` in a third process. The parent process then tries to kill both children on expiry of a timeout. The script behaves perfectly on Linux -- it works as expected and kills the fork-ed child Perl process, as well it's `sleep` child process. However, on Cygwin/Perl it only kills the fork-ed Perl child - it cannot kill the `sleep`-ing child. The problem seems to be that the process table data returned by Proc::ProcessTable seems to differ from the data returned 'ps'. Specifically, Proc::ProcessTable returns the WINPID of a process as the PID for the backticked `sleep` process. The closest issue I found in the list archives is this one: http://sourceware.org/ml/cygwin/2005-02/msg00224.html It does not seem to have been resolved. I'm running Perl on Cygwin on Windows XP SP2. Running 'cygcheck -c' gives the following package status for cygwin and Perl: -- cygwin 1.5.16-1 OK perl5.8.6-4OK -- Can anyone help? Regards, Sonam Chauhan -- Electronic Commerce, Corporate Express Australia Ltd. Phone: +61-2-9335-0725, Email: [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ timeout_test2.pl Description: Binary data -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: problems in Perl process management
that's by design if u want to kill an entire tree u can do so with process explorer a free download from www.sysinternals.com. Steve - Original Message - From: Jurgen Defurne I also would like to know if it is possible. However, it could be that it has nothing to do with Cygwin. I have a Perl script which forks several children and monitors their output. If a child fails, then it has no use to run all forked processes further and I kill them with the perl 'kill' command. However, I also notice that deeper forked processes (grandchildren) refuse to die. This script is only run using ActiveState Perl. I think it is really a serious Windows problem, because using the task manager it also seems not really possible to kill a complete process hierarchy. This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137 or return the E.mail to [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: problems in Perl process management
On Tue, May 10, 2005 at 01:12:05PM +0200, Jurgen Defurne wrote: I also would like to know if it is possible. However, it could be that it has nothing to do with Cygwin. I have a Perl script which forks several children and monitors their output. If a child fails, then it has no use to run all forked processes further and I kill them with the perl 'kill' command. However, I also notice that deeper forked processes (grandchildren) refuse to die. This script is only run using ActiveState Perl. ActiveState perl is a windows program. You can't send cygwin (aka unix) signals to a windows proram. I think it is really a serious Windows problem, because using the task manager it also seems not really possible to kill a complete process hierarchy. XP has an option for killing the process hierarchy. Just right click on the process. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: problems in Perl process management
Hello to Reini Urban and Yitzchak Scott-Thoennes if you're seeing this. Reine, Yitzchak - Back in Feb, you had a discussion: http://sourceware.org/ml/cygwin/2005-02/msg00224.html Do you think the issue below is related to it? Also, at that time Yitzchak had proposed a patch - do you know what the status of that is? Jurgen - I think this is not a Windows problem but a Perl/Cygwin problem. Our experiences may be related. How do you determine the grandchild PID - was it returned by fork, or did you use the Proc::Killfam and Proc::ProcessTable Perl modules? I use these modules for convenience and some debug code showed that they simply do not recognize the grandchildren as sub-children of the parent PID. The reason is probably the issue mentioned in the URL -- ProcessTable wrongly showing WINPIDs as Cygwin PIDs. Hi Christopher - your response to Jurgen had mentioned: ActiveState perl is a windows program. You can't send cygwin (aka unix) signals to a windows proram. This should be possible if the ActiPerl Windows executable was executed from a Cygwin terminal -- 'ps' shows it running and 'kill -9' should kill it. Regards, Sonam Chauhan -- Electronic Commerce, Corporate Express Australia Ltd. Phone: +61-2-9335-0725, Email: [EMAIL PROTECTED] -Original Message- From: Jurgen Defurne [mailto:[EMAIL PROTECTED] Sent: Tuesday, 10 May 2005 9:12 PM To: Sonam Chauhan Cc: cygwin@cygwin.com Subject: Re: problems in Perl process management I also would like to know if it is possible. However, it could be that it has nothing to do with Cygwin. I have a Perl script which forks several children and monitors their output. If a child fails, then it has no use to run all forked processes further and I kill them with the perl 'kill' command. However, I also notice that deeper forked processes (grandchildren) refuse to die. This script is only run using ActiveState Perl. I think it is really a serious Windows problem, because using the task manager it also seems not really possible to kill a complete process hierarchy. Regards, Jurgen Defurne Sonam Chauhan [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 2005-05-10 10:41 AM To: 'cygwin@cygwin.com' cygwin@cygwin.com cc: (bcc: Jurgen Defurne/BRG/CE/PHILIPS) Subject:problems in Perl process management Classification: Hello - I'd appreciate help with problems doing process management in Cygwin/Perl. I have a Perl application that creates child processes - I need it to kill processes that exceed a certain timeout. I am trying to use the Proc::ProcessTable and Proc::Killfam CPAN modules for this. I ran into two problems: The first problem was a can't stat /dev error message produced when calling Proc::Killfam. This problem was fixed by a script I found that populated entries under /dev. To understand the next probem, have a look at the simple test script attached. The script forks a child process, which runs `sleep` in a third process. The parent process then tries to kill both children on expiry of a timeout. The script behaves perfectly on Linux -- it works as expected and kills the fork-ed child Perl process, as well it's `sleep` child process. However, on Cygwin/Perl it only kills the fork-ed Perl child - it cannot kill the `sleep`-ing child. The problem seems to be that the process table data returned by Proc::ProcessTable seems to differ from the data returned 'ps'. Specifically, Proc::ProcessTable returns the WINPID of a process as the PID for the backticked `sleep` process. The closest issue I found in the list archives is this one: http://sourceware.org/ml/cygwin/2005-02/msg00224.html It does not seem to have been resolved. I'm running Perl on Cygwin on Windows XP SP2. Running 'cygcheck -c' gives the following package status for cygwin and Perl: -- cygwin 1.5.16-1 OK perl5.8.6-4OK -- Can anyone help? Regards, Sonam Chauhan -- Electronic Commerce, Corporate Express Australia Ltd. Phone: +61-2-9335-0725, Email: [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: problems in Perl process management
On Wed, May 11, 2005 at 01:19:14PM +1000, Sonam Chauhan wrote: Hi Christopher - your response to Jurgen had mentioned: ActiveState perl is a windows program. You can't send cygwin (aka unix) signals to a windows proram. This should be possible if the ActiPerl Windows executable was executed from a Cygwin terminal -- 'ps' shows it running and 'kill -9' should kill it. I guess I forgot my signature. -- Christopher Faylor spammer? - [EMAIL PROTECTED] Cygwin Co-Project Leader[EMAIL PROTECTED] TimeSys, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: problems in Perl process management
On Tue, May 10, 2005 at 11:22:49PM -0400, Christopher Faylor wrote: On Wed, May 11, 2005 at 01:19:14PM +1000, Sonam Chauhan wrote: Hi Christopher - your response to Jurgen had mentioned: ActiveState perl is a windows program. You can't send cygwin (aka unix) signals to a windows proram. This should be possible if the ActiPerl Windows executable was executed from a Cygwin terminal -- 'ps' shows it running and 'kill -9' should kill it. I guess I forgot my signature. Actually, let me clarify without being flip. Yes, if you send a kill -9 to a pid that shows up in ps but is associated with a non-cygwin process, it should work. Other non-terminating signals will not work, and a blockable terminating signal like SIGTERM won't work. If you try to send any kind of signal to the windows pid, it won't work. I'm sorry that I wasn't entirely clear in my original reply. -- Christopher Faylor spammer? - [EMAIL PROTECTED] Cygwin Co-Project Leader[EMAIL PROTECTED] TimeSys, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
