This is the mail archive of the
mailing list for the cygwin project.
Re: /bin/kill -f WINPID; for a rogue cygwin process?
- From: Igor Peshansky <pechtcha at cs dot nyu dot edu>
- To: The Cygwin-Talk Maiming List <cygwin-talk at cygwin dot com>
- Date: Mon, 10 Dec 2007 14:07:34 -0500 (EST)
- Subject: Re: /bin/kill -f WINPID; for a rogue cygwin process?
- References: <200712080159.lB81x5Vt009005@tigris.pounder.sol.net>
- Reply-to: The Cygwin-Talk Maiming List <cygwin-talk at cygwin dot com>
- Reply-to: The Vulgar and Unprofessional Cygwin-Talk List <cygwin-talk at cygwin dot com>
On Fri, 7 Dec 2007, Tom Rodman wrote:
> There may not be enough info in this post, also it pertains to
> an old cygwin release( 1.5.20s(0.155/4/2) 20060403 13:33:45 ).
> I'm hoping it will be tolerated in cygwin-talk.
> I have been trying to understand how to clean up rogue cygwin
> processes that appear after days or weeks of uptime ( and many
> cron jobs ) - defunct and "unknown" processes for example.
> "pidtablecygcheck00" is a simple bash script that uses cygwin ps,
> and /proc, and sysinternals: pslist and 'handle cygwin' - output;
> it compares/joins their reports. I show that script's output,
> since it may help, but the script is not the point...
> The question I have concerns the "/bin/kill -f" shown in the bash
> session record on a windows 2003 server w/hostname "OurHost",
> below my sig. Windows pid 6588 was a bash.exe process, that did
> not show up in 'ps -elW', so I thought I should cleanup:
> /tmp $ command ps -elW|grep 6588
> /tmp $
> /tmp $ /bin/kill -f 6588
> kill: couldn't open pid 6340
> Windows shown 6588, was still there, so I right clicked on 6588
> in sysinternals procexp, and selected properties- at that point
> things for the process seemed ordinary to my layman eyes, then I
> closed procexp, and process 6588 had vanished! (I have seen this
> Any ideas/comments, especially about the 'kill: couldn't open pid 6340'?
> 6340?! ... OK 6340 shows up has the Windows PID for cygwin process
> 7260, but I still need help unraveling this. (search this post for 6340)
> Less importantly, why does '/proc/6588/' exist, when
> `command ps -elW|grep 6588` returns nothing?
FWIW, I've seen Process Explorer itself occasionally hold on to process
handles and memory... When I quit Process Explorer, the process count
went down and the memory was released. Could that be the explanation
|\ _,,,---,,_ email@example.com | firstname.lastname@example.org
ZZZzz /,`.-'`' -. ;-;;,_ Igor Peshansky, Ph.D. (name changed!)
|,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
"That which is hateful to you, do not do to your neighbor. That is the whole
Torah; the rest is commentary. Go and study it." -- Rabbi Hillel