This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Weird top bug?

cygcheck output attached, two ways.

I noticed that one tool I recently installed has some cygwin-ish-ness to it
that I had not expected.  It's shown in the output, but I thought I'd
highlight it.  Flexgdb has some dlls that cygcheck found.  I renamed the
directory to hide it from PATH, rebooted, and tried again.  Same thing
happens; cygcheck.out.2 shows the slightly different setup.  However, I just
saw something else this time.  When top is sitting there stuck, and you kill
the window that vping still has the console locked, THEN top sits for a few
more seconds, then comes up as one would expect.  Seems like top is actually
blocked trying to get at some windows resource that the closing shell has

On Fri, Jun 06, 2003 at 03:40:24PM -0400, Ashok Vadekar wrote:
> I've stumbled across some peculiar behaviour for top.  I've got the following
> script (vping) that I use to keep a VPN connection alive:
> 	#!/bin/sh
> 		while true;
> 		do
> 			ping -n 1 remoteMachine >/dev/null
> 			sleep 60
> 		done
> I typically run this as a background task (vping &), then telnet to
> remoteMachine.
> Now when I quit telnet, then exit the shell (vping was run from), the shell
> stays around.  My script has a stdout handle, I suppose.  That's OK, I can
> close the window with the mouse, and then vping dies.  Seems normal.  But if I
> leave the shell open after typing exit, then run top in another shell, it
> clears the screen, shows exactly one line of output (in this specific case):
> 	 15:23:03 up  8:00,  2 users,  load average: 0.00, 0.00, 0.00
> and locks up.  Control C does not regain shell control.
> If I open another shell and use ps to find the process number for top, I can
> kill it (kill pid, no explicit signal type).
> It doesn't seem to me that my specific script should have anything to do with
> how top is behaving, but I supose it is possible.  Seems more like top is
> having trouble because the parent process of my script is no longer valid.
> Maybe the parent process is gone, but top uses a windows thing to enumerate
> processes, and the open shell still has an entry in that list?
> --
> Unsubscribe info:
> Problem reports:
> Documentation:
> FAQ:         

Attachment: cygcheck.out
Description: Text document

Attachment: cygcheck.out.2
Description: Text document

Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]