This is the mail archive of the
mailing list for the cygwin project.
Re: /bin/kill -f WINPID; for a rogue cygwin process?
On Mon 12/10/07 14:07 EST The Cygwin-Talk Maiming List wrote:
> On Fri, 7 Dec 2007, Tom Rodman wrote:
> > 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 $
> > --snip
> > /tmp $ /bin/kill -f 6588
> > kill: couldn't open pid 6340
My hunch- once a cygwin process no longer shows up in `ps -elW`,
one should use a non-cygwin approach to kill it. Over the last
several years I've been using cygwin '/bin/kill -f' in an ssh
session to kill both windows and non windows processes ( that the
user in the ssh session owns ) with good results. I plan to stop
this approach and use sysinternals 'pskill' unless I'm dealing w/a
normal cygwin process.
> > 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
> > before.)
> > 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
Thanks Igor, but the 6588 bash.exe process was there for (hours?)
prior to me right clicking on it w/Process Explorer; I started
(the only instance of) Process Explorer just prior to right
clicking the process.
The fact that the process vanished was interesting, but my main question
is why did 'kill' want to open pid 6340?