RE: Problem installing CPAN module
Thanks a lot Lasse - your PID_ZOMBIE - PID_UNUSED rename trick worked a treat. At that time, cygcheck showed the core 'cygwin' version as 1.5.16-1. The 'cygwin' version is now 1.5.17-1. The versions of Cygwin Perl (5.8.6-4) and CPAN Proc::ProcessTable version (0.39) have not changed. Any thought on what the problem might be? It seems the problem with Proc::ProcessTable picking up the wrong PID (i.e. Win PID instead of Cygwin PID) is still around... I'm not really familiar with cygwin's internals so I'm not sure what to do about that... Actually I put down those versions numbers attempting to narrow down the cause of PID_ZOMBIE problem. Chris suggested a workaround to the Win PID/Cygwin PID problem - I recorded this in the bugs I logged in both the CPAN and SourceForge bug lists (not sure where the maintenance for this module is taking place): http://rt.cpan.org/NoAuth/Bug.html?id=12840 http://sourceforge.net/tracker/index.php?func=detailaid=1222359group_id=81 217atid=562305 In case someone else finds it useful, I had hit a problem with calling Proc::Killfam in Perl - it died with a can't stat /dev error on Cygwin. The following script by Igor Pechtchanski fixed the problem. http://www.cygwin.com/ml/cygwin/2004-03/msg01421.html Thanks Igor! Cheers, Sonam -Original Message- From: Lasse [mailto:[EMAIL PROTECTED] Sent: Thursday, 23 June 2005 4:18 AM To: cygwin@cygwin.com Subject: Re: Problem installing CPAN module Sonam Chauhan wrote: Hi - While doing a fresh install of Cygwin, I have run into errors installing a CPAN Perl module that worked last month. The module is Proc::ProcessTable. It now reports a `PID_ZOMBIE' undeclared error message during compilation. The relevant snippet is below. Hmm... This rings a bell... *digging through old CPAN build cache* Yup, here it is... Appearantly the cygwin.h include file changed at some point and the PID_ZOMBIE definition disappeared. Seems like the PID_UNUSED definition replaced it though. At least it has the same value. So, I just replaced PID_ZOMBIE with PID_UNUSED in Proc::ProcessTable's os/cygwin.c and voila! It builds... Whether that's the correct definition to be used there, I have no idea but it seems to work fine... I actually thought I had submitted a patch for this but I must have forgotten... Back in May, I reported a different problem with this module: http://www.mail-archive.com/cygwin@cygwin.com/msg54579.html At that time, cygcheck showed the core 'cygwin' version as 1.5.16-1. The 'cygwin' version is now 1.5.17-1. The versions of Cygwin Perl (5.8.6-4) and CPAN Proc::ProcessTable version (0.39) have not changed. Any thought on what the problem might be? It seems the problem with Proc::ProcessTable picking up the wrong PID (i.e. Win PID instead of Cygwin PID) is still around... I'm not really familiar with cygwin's internals so I'm not sure what to do about that... But at least it builds now.. ;-) -- /Lasse -- 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/
Problem installing CPAN module
Hi - While doing a fresh install of Cygwin, I have run into errors installing a CPAN Perl module that worked last month. The module is Proc::ProcessTable. It now reports a `PID_ZOMBIE' undeclared error message during compilation. The relevant snippet is below. Back in May, I reported a different problem with this module: http://www.mail-archive.com/cygwin@cygwin.com/msg54579.html At that time, cygcheck showed the core 'cygwin' version as 1.5.16-1. The 'cygwin' version is now 1.5.17-1. The versions of Cygwin Perl (5.8.6-4) and CPAN Proc::ProcessTable version (0.39) have not changed. Any thought on what the problem might be? Regards, Sonam $perl -e install Proc::ProcessTable -MCPAN ... gcc -c -DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -pipe -I/usr/local/include -DUSEIMPORTLIB -O3 -DVERSION=\0.39\ -DXS_VERSION=\0.39\ -I/usr/lib/perl5/5.8/cygwin/CORE OS.c OS.c: In function `OS_get_table': OS.c:212: error: `PID_ZOMBIE' undeclared (first use in this function) OS.c:212: error: (Each undeclared identifier is reported only once OS.c:212: error: for each function it appears in.) make: *** [OS.o] Error 1 /usr/bin/make -- NOT OK Running make test Can't test without successful make Running make install make had returned bad status, install seems impossible -- 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
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
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
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
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
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
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: Please test latest snapshot
Corinna Vinschen said: You can now list servers in the machine's domain/workgroup with $ ls // Since some (most?) Unix shells have a convenience feature to reinterpret multiple forward slashes as a single slash, could this behavior break existing scripts or makefiles? Also, there is a strange discrepancy in how the current (non-snapshot) version of Cygwin 1.5.16-1 handles multiple forward slashes. I compared it's handling of some 'ls' commands to that of bash on Linux RHAS 2.1. When listing '/', all the following commands work the same on both systems: 1. ls / 2. ls // 3. ls /// 4. ls However, when listing a directory under '/', command #2 behaves differently in Cygwin: 1. ls /etc 2. ls //etc (* - fails only on Cygwin, see below) 3. ls ///etc 4. ls etc (*) On Cygwin, command #2 returns: - $ ls //etc ls: //etc: No such file or directory - Regards, Sonam Chauhan -- Electronic Commerce, Corporate Express Australia Ltd. Phone: +61-2-9335-0725, Email: [EMAIL PROTECTED] -Original Message- From: Corinna Vinschen [mailto:[EMAIL PROTECTED] Sent: Saturday, 14 May 2005 8:07 AM To: cygwin@cygwin.com Subject: Please test latest snapshot -- 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: Please test latest snapshot
This is per the Single Unix Specification; three or more slashes are required to be equivalent to one slash, while two slashes are explicitly reserved for operating system dependent behaviour (in cygwin's case, //server). Thanks for the clarification Yitzchak - that does make sense. So, a good reason to test is Cygwin's handling of 'ls //' has changed - from listing the root directory, to listing servers in the workgroup/domain. 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
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
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
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
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/
problems in Perl process management
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] 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
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/
