Re: Bash process remains after I close rxvt in certain ways
Charles Wilson wrote: rxvt-20050409-4 (e.g. the test version now on the mirrors) also has a common behavior across all three cases, but that behavior is different than the behavior described above. The new rxvt exits and sighups the child (which obligingly goes ahead and dies; no zombies) in all three cases. You might also want to have a look at http://www.cygwin.com/ml/cygwin/2006-12/msg00712.html Here I see that all the child processes are not ended, this is with rxvt-20050409-4. Closing the window is performed by clicking the "X" on the top right under Windows XP SP2. Short of modifying any code, is there more information I can provide? It appears to work okay for me -- but I'll wait for comments on the test release before I promote it. -- Chuck -- 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: Bash process remains after I close rxvt in certain ways
Corinna Vinschen wrote:
So there's something missing in the picture here... What does happen in
rxvt when Alt-F4 is pressed. Nothing?
rxvt-20050409-3 (e.g. the current version) behaves the same way in all
three cases:
kill -HUP
alt-f4 when rxvt has the focus
click on the 'x' button in the rxvt window
in each case, the current version of rxvt exits but leaves behind a
zombie bash shell (assuming bash was the target cmd processor).
rxvt-20050409-4 (e.g. the test version now on the mirrors) also has a
common behavior across all three cases, but that behavior is different
than the behavior described above. The new rxvt exits and sighups the
child (which obligingly goes ahead and dies; no zombies) in all three cases.
--
Chuck
P.S. Here's the relevant changes between -3 and -4:
src/main.c
@@ -155,6 +155,9 @@ rxvt_Exit_signal
#ifdef DEBUG_CMD
rxvt_print_error("signal %d", sig);
#endif
+// pass signal on to child cmd processor
+rxvt_t *r = rxvt_get_r();
+kill(r->h->cmd_pid, sig);
rxvt_clean_exit();
kill(getpid(), sig);
}
@@ -200,6 +203,8 @@ rxvt_clean_exit
r->h->Input_Context = NULL;
}
#endif
+// terminal is dying, tell child cmd processor
+kill(r->h->cmd_pid, SIGHUP);
}
The first hunk is in the signal handler that the parent rxvt registers
for SIGHUP, SIGINT, SIGQUIT, and SIGTERM -- and ensures that those
signals are passed along to the child. The second hunk is in
rxvt_clean_exit, which is explicitly called in some other fatal-error
situations and is registered with atexit/on_exit.
Note that because rxvt_Exit_signal handler calls rxvt_clean_exit, the
child may get two HUPs, or (whatever rxvt_Exit_signal got) and a HUP --
or, if rxvt_clean_exit was called via another mechanism, then the child
will get only a single HUP.
It appears to work okay for me -- but I'll wait for comments on the test
release before I promote it.
--
Chuck
--
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: Bash process remains after I close rxvt in certain ways
On Dec 6 03:57, Charles Wilson wrote: > [nothin' like resurrecting a month-old thread...] > > Christopher Faylor wrote: > > >This is handled in dcrt0.cc:do_exit(). I'm wondering if rxvt is not > >dealing with the SIGHUP that cygwin should be sending to it on > >CTRL_CLOSE, though. > > Well, rxvt *does* respond to SIGHUP: > > $ ps -eaf # output snipped > cwilson3796 1 con 01:22:47 /usr/bin/rxvt > cwilson 3923796 3 01:22:47 /usr/bin/bash > > $ kill -HUP 3796 > > $ ps -eaf # output snipped > cwilson 392 1 3 01:22:47 /usr/bin/bash > > but leaves behind a zombified bash. Further, because rxvt is compiled > as a console app, Windows does not send a WM_CLOSE message when you > press Alt-F4 or click the 'x' button: for console apps it sends a > CTRL_CLOSE_EVENT, which is intercepted by cygwin and translated into > SIGHUP -- so my discussion here: > http://cygwin.com/ml/cygwin/2006-11/msg00312.html I just debugged this a little bit purely from the Cygwin perspective and I found that Cygwin does not get a CTRL_CLOSE_EVENT when you press the X button of the rxvt window or press Alt-F4. The explanation for the orphaned shell must be a bit more tricky. When running strace, I'm wondering about the below when, for instance, Alt-F4 is pressed: 24 1990559 [main] rxvt 3748 kill_pgrp: pid 3748, signal -1 [...] 31 1991910 [main] rxvt 3748 __set_errno: int kill_pgrp(pid_t, siginfo_t&):314 val 3 23 1991933 [main] rxvt 3748 kill_pgrp: -1 = kill (3748, -1) So, what happens is that rxvt only tries to kill its own process group. This won't kill the shell which is the process group leader of its own process group. So there's something missing in the picture here... What does happen in rxvt when Alt-F4 is pressed. Nothing? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: Bash process remains after I close rxvt in certain ways
[nothin' like resurrecting a month-old thread...]
Christopher Faylor wrote:
This is handled in dcrt0.cc:do_exit(). I'm wondering if rxvt is not
dealing with the SIGHUP that cygwin should be sending to it on
CTRL_CLOSE, though.
Well, rxvt *does* respond to SIGHUP:
$ ps -eaf # output snipped
cwilson3796 1 con 01:22:47 /usr/bin/rxvt
cwilson 3923796 3 01:22:47 /usr/bin/bash
$ kill -HUP 3796
$ ps -eaf # output snipped
cwilson 392 1 3 01:22:47 /usr/bin/bash
but leaves behind a zombified bash. Further, because rxvt is compiled
as a console app, Windows does not send a WM_CLOSE message when you
press Alt-F4 or click the 'x' button: for console apps it sends a
CTRL_CLOSE_EVENT, which is intercepted by cygwin and translated into
SIGHUP -- so my discussion here:
http://cygwin.com/ml/cygwin/2006-11/msg00312.html
is not really germane, unless I recompile rxvt as a GUI app (however,
doing that breaks usages with run.exe, so that's no good).
FWIW, rxvt during its initialization does the following:
...
# ifdef HAVE_SETSID
setsid();
# endif
# if defined(HAVE_SETPGID)
setpgid(0, 0);
# elif defined(HAVE_SETPGRP)
setpgrp(0, 0);
# endif
...
followed by a bunch of stuff to set the controlling tty
I verified using strace that indeed, setsid() and setpgid() are called
-- but they happen AFTER the fork(), in the child process that
eventually execs bash:
/* spin off the command interpreter */
switch (r->h->cmd_pid = fork()) {
case -1:
rxvt_print_error("can't fork");
return -1;
case 0:
/* this is the child */
close(cfd); * only keep r->tty_fd and STDERR open */
close(r->Xfd);
[ rxvt_control_tty() is where setsid and setpgid are called ]
if (rxvt_control_tty(r->tty_fd, r->h->ttydev) < 0)
rxvt_print_error("could not obtain control of tty");
else {
/* Reopen stdin/out/err over the tty file descriptor */
dup2(r->tty_fd, STDIN_FILENO);
dup2(r->tty_fd, STDOUT_FILENO);
dup2(r->tty_fd, STDERR_FILENO);
if (r->tty_fd > 2)
close(r->tty_fd);
rxvt_run_child(r, argv);
}
exit(EXIT_FAILURE);
/* NOTREACHED */
default:
/* this is the original process */
...
So rxvt itself isn't the session leader or the group leader for the
child cmd processor (bash)...which is why HUP/KILL don't propagate to
the child.
Now, I dunno why rxvt works as-is on unix -- maybe bash on linux notices
that its terminal is gone and exits. But it seems to me that in this
case, on cygwin, rxvt -- and not cygwin1.dll -- needs to forward SIGHUP
to its child process.
I'll got a local version that does propagate (some) signals to the
child, and it seems to eliminate the bad behavior (no zombies) -- but
I'm not sure what other ramifications this change may have.
I've got a test release on sourceware now; I'll announce it in a new
thread and call for testing, once it has propagated to the mirrors.
--
Chuck
--
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: Bash process remains after I close rxvt in certain ways
The problem I've been having for quite a while now may or may not be related to this but it's indeed similar. I start XWin from a batch file that also starts a gnome-terminal. I always have to kill the gnome-pty-helper.exe process in order to be able to open more terminals. The point where it hangs varies from just creating the second terminal to up to maybe the 7th. I've never seen it go beyond that before needing to kill the helper process. This issue made me start a Sysinternals's Process Explorer window as a pre-requisite to starting XWin and the gnome-terminals. I now start XWin and then look in the process explorer window for the gnome-pty-helper process, kill it and then watch the rest of the terminals come up. If I look at the threads in the gnome-pty-helper.exe process, I find two threads, one doing about 92 context switches per second with a start address at 'gnome-pty-helper.exe+0x1000' and the other one is at cygwin1.dll!toascii+0x15d0. This second one is a pretty common address I see when I get cygwin runaway processes using 100% CPU but that's a different story I think (or maybe not?) I've killed that thread only to see if it would help but it looks like something is waiting for the process to finish because things only keep rolling after I kill the process not just the thread. Mind you, sometimes it doesn't happen right away, that is, the second terminal starts find even though the gnome-pty-helper.exe is still there. The other relatead issue is that when I exit the last bash shell in the gnome-terminals, the gnome-terminal.exe process doesn't go away either and I have to kill that one too. Well, actually, Process Explorer says the the gnome-terminal.exe process is a child of a bash.exe process as expected I guess but there are other bash shells, those in each gnome terminal window or tab, which where started by gnome-terminal. They show up as siblings and not as children though. When I kill the gnome-terminal.exe process, the bash.exe parent process goes away by itself. It all seems related to gnome-terminal and the related supporting gnome packages and not to bash itself, which is basically why I haven't posted anything about this here but this time it seems at least somebody might tell me that indeed it's not and point in a more hopeful direction. Thanks -- Luis P Caamano Atlanta, GA USA On 13 Nov 2006 15:08:48 -, [EMAIL PROTECTED] Igor Peshansky wrote: > According to Eric Lilja on 11/12/2006 12:52 PM: > > I recently upgraded to a dual core machine which made me use the windows > > task manager alot. That's when I noticed that if I close the rxvt window > > by pressing 'x' in the top right corner (or doing alt-f4, I never do > > this, just tried it now to see what happened) the rxvt process is > > terminated and the window disappears but the "underlying" bash process > > is still running (without a visible window), consuming ~3.5 MB of memory > > and 0 cpu time according to the task manager. > > So far, no one has found a good way for a cygwin process killed by Alt-F4 > (or the X button) to treat that as a SIGHUP and pass that information on > to all of its children processes. So, by killing rxvt abruptly, you are > indeed stranding bash as a zombie process. > > > If I exit rxvt by typing > > exit, the bash process is terminated too. > > Actually, typing exit will exit bash, not rxvt; but when rxvt realizes > that all of its children processes have exited, it exits as well. > > > Can I do something so the bash > > process is always terminated properly no matter how I close the rxvt > > window? > > Submit a patch to make cygwin processes recognize Alt-F4 as a SIGHUP that > needs to be passed to their children? Or possibly even a patch such that > when a controlling pty terminal is closed, all children (such as bash) > reading from that pty get an end-of-input (possibly a SIGPIPE) when trying > to read from the disappearing terminal? Actually, it's not the Cygwin processes that need that feature, but the W11 library. When rxvt is closed via the 'X' button or Alt-F4, Windows sends it the WM_QUIT message, which ought to be handled properly in the library as application exit (and thus send SIGHUP to all immediate children). This is done by the Cygwin console already, so it may simply be a matter of copying/pasting some code... > > Is there misconfiguration on my end or should I simply get in > > the habit of always using exit to close rxvt? > > For now, that is the best course of action. -- 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: Bash process remains after I close rxvt in certain ways
On Mon, Nov 13, 2006 at 03:18:56PM +, Eric Blake wrote: >Charles Wilson cwilson.fastmail.fm> writes: > >> Or what *should* be happening. >> >> So, I think that in src/command.c, right before exit() is called, rxvt >> ought to kill its children -- except I thought exit() should do that >> already? > >http://www.opengroup.org/onlinepubs/009695399/functions/exit.html: >"Termination of a process does not directly terminate its children. The >sending >of a SIGHUP signal as described below indirectly terminates children in some >circumstances. >... >"If the process is a controlling process, the SIGHUP signal shall be sent to >each process in the foreground process group of the controlling terminal >belonging to the calling process. >"If the process is a controlling process, the controlling terminal associated >with the session shall be disassociated from the session, allowing it to be >acquired by a new controlling process. >"If the exit of the process causes a process group to become orphaned, and if >any member of the newly-orphaned process group is stopped, then a SIGHUP >signal >followed by a SIGCONT signal shall be sent to each process in the newly- >orphaned process group." > >Sounds like you are right - rxvt should be a controlling process, so calling >exit() should automatically cause cygwin to send SIGHUP to the process group, >and rxvt shouldn't have to do any manual killing. This is handled in dcrt0.cc:do_exit(). I'm wondering if rxvt is not dealing with the SIGHUP that cygwin should be sending to it on CTRL_CLOSE, though. 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: Bash process remains after I close rxvt in certain ways
Charles Wilson cwilson.fastmail.fm> writes: > Or what *should* be happening. > > So, I think that in src/command.c, right before exit() is called, rxvt > ought to kill its children -- except I thought exit() should do that > already? http://www.opengroup.org/onlinepubs/009695399/functions/exit.html: "Termination of a process does not directly terminate its children. The sending of a SIGHUP signal as described below indirectly terminates children in some circumstances. ... "If the process is a controlling process, the SIGHUP signal shall be sent to each process in the foreground process group of the controlling terminal belonging to the calling process. "If the process is a controlling process, the controlling terminal associated with the session shall be disassociated from the session, allowing it to be acquired by a new controlling process. "If the exit of the process causes a process group to become orphaned, and if any member of the newly-orphaned process group is stopped, then a SIGHUP signal followed by a SIGCONT signal shall be sent to each process in the newly- orphaned process group." Sounds like you are right - rxvt should be a controlling process, so calling exit() should automatically cause cygwin to send SIGHUP to the process group, and rxvt shouldn't have to do any manual killing. -- Eric Blake -- 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: Bash process remains after I close rxvt in certain ways
Eric Blake wrote: So far, no one has found a good way for a cygwin process killed by Alt-F4 (or the X button) to treat that as a SIGHUP and pass that information on to all of its children processes. So, by killing rxvt abruptly, you are indeed stranding bash as a zombie process. Actually, I think rxvt/W11 already handles some of this; in W11/w32/event.c, MSWin messages WM_DESTROY, WM_QUIT, and WM_CLOSE ... case WM_DESTROY: case WM_QUIT: case WM_CLOSE: event->type = ClientMessage; event->xclient.format = 32; event->xclient.data.l[0] = XInternAtom(NULL,"WM_DELETE_WINDOW", FALSE); break; ... are all turned into an X11-style XA_WMDELETEWINDOW message, which is then handled (in src/command.c) by case ClientMessage: if (ev->xclient.format == 32 && (Atom)ev->xclient.data.l[0] == h->xa[XA_WMDELETEWINDOW]) exit(EXIT_SUCCESS); (There is a little translation between the string "WM_DELETE_WINDOW", the struct h->xa, and the enum which defines XA_WMDELETEWINDOW, but that's basically what happens). Or what *should* be happening. So, I think that in src/command.c, right before exit() is called, rxvt ought to kill its children -- except I thought exit() should do that already? -- Chuck -- 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: Bash process remains after I close rxvt in certain ways
On Mon, Nov 13, 2006 at 08:15:15AM -0500, Igor Peshansky wrote: >On Mon, 13 Nov 2006, Eric Blake wrote: > >> According to Eric Lilja on 11/12/2006 12:52 PM: >> > I recently upgraded to a dual core machine which made me use the windows >> > task manager alot. That's when I noticed that if I close the rxvt window >> > by pressing 'x' in the top right corner (or doing alt-f4, I never do >> > this, just tried it now to see what happened) the rxvt process is >> > terminated and the window disappears but the "underlying" bash process >> > is still running (without a visible window), consuming ~3.5 MB of memory >> > and 0 cpu time according to the task manager. >> >> So far, no one has found a good way for a cygwin process killed by Alt-F4 >> (or the X button) to treat that as a SIGHUP and pass that information on >> to all of its children processes. So, by killing rxvt abruptly, you are >> indeed stranding bash as a zombie process. >> >> > If I exit rxvt by typing >> > exit, the bash process is terminated too. >> >> Actually, typing exit will exit bash, not rxvt; but when rxvt realizes >> that all of its children processes have exited, it exits as well. >> >> > Can I do something so the bash >> > process is always terminated properly no matter how I close the rxvt >> > window? >> >> Submit a patch to make cygwin processes recognize Alt-F4 as a SIGHUP that >> needs to be passed to their children? Or possibly even a patch such that >> when a controlling pty terminal is closed, all children (such as bash) >> reading from that pty get an end-of-input (possibly a SIGPIPE) when trying >> to read from the disappearing terminal? > >Actually, it's not the Cygwin processes that need that feature, but the >W11 library. When rxvt is closed via the 'X' button or Alt-F4, Windows >sends it the WM_QUIT message, which ought to be handled properly in the >library as application exit (and thus send SIGHUP to all immediate >children). This is done by the Cygwin console already, so it may simply >be a matter of copying/pasting some code... Actually, Cygwin sends a SIGHUP to the process being closed when it sees a CTRL_CLOSE_EVENT. Maybe it just needs to send a SIGHUP to the entire process group rather than just the one process. I'll look into that. 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: Bash process remains after I close rxvt in certain ways
On Mon, 13 Nov 2006, Eric Blake wrote: > According to Eric Lilja on 11/12/2006 12:52 PM: > > I recently upgraded to a dual core machine which made me use the windows > > task manager alot. That's when I noticed that if I close the rxvt window > > by pressing 'x' in the top right corner (or doing alt-f4, I never do > > this, just tried it now to see what happened) the rxvt process is > > terminated and the window disappears but the "underlying" bash process > > is still running (without a visible window), consuming ~3.5 MB of memory > > and 0 cpu time according to the task manager. > > So far, no one has found a good way for a cygwin process killed by Alt-F4 > (or the X button) to treat that as a SIGHUP and pass that information on > to all of its children processes. So, by killing rxvt abruptly, you are > indeed stranding bash as a zombie process. > > > If I exit rxvt by typing > > exit, the bash process is terminated too. > > Actually, typing exit will exit bash, not rxvt; but when rxvt realizes > that all of its children processes have exited, it exits as well. > > > Can I do something so the bash > > process is always terminated properly no matter how I close the rxvt > > window? > > Submit a patch to make cygwin processes recognize Alt-F4 as a SIGHUP that > needs to be passed to their children? Or possibly even a patch such that > when a controlling pty terminal is closed, all children (such as bash) > reading from that pty get an end-of-input (possibly a SIGPIPE) when trying > to read from the disappearing terminal? Actually, it's not the Cygwin processes that need that feature, but the W11 library. When rxvt is closed via the 'X' button or Alt-F4, Windows sends it the WM_QUIT message, which ought to be handled properly in the library as application exit (and thus send SIGHUP to all immediate children). This is done by the Cygwin console already, so it may simply be a matter of copying/pasting some code... > > Is there misconfiguration on my end or should I simply get in > > the habit of always using exit to close rxvt? > > For now, that is the best course of action. If you don't want to go looking at the guts of the W11 library, yes. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! "Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte." "But no -- you are no fool; you call yourself a fool, there's proof enough in that!" -- Rostand, "Cyrano de Bergerac" -- 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: Bash process remains after I close rxvt in certain ways
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Eric Lilja on 11/12/2006 12:52 PM: > I recently upgraded to a dual core machine which made me use the windows > task manager alot. That's when I noticed that if I close the rxvt window > by pressing 'x' in the top right corner (or doing alt-f4, I never do > this, just tried it now to see what happened) the rxvt process is > terminated and the window disappears but the "underlying" bash process > is still running (without a visible window), consuming ~3.5 MB of memory > and 0 cpu time according to the task manager. So far, no one has found a good way for a cygwin process killed by Alt-F4 (or the X button) to treat that as a SIGHUP and pass that information on to all of its children processes. So, by killing rxvt abruptly, you are indeed stranding bash as a zombie process. > If I exit rxvt by typing > exit, the bash process is terminated too. Actually, typing exit will exit bash, not rxvt; but when rxvt realizes that all of its children processes have exited, it exits as well. > Can I do something so the bash > process is always terminated properly no matter how I close the rxvt > window? Submit a patch to make cygwin processes recognize Alt-F4 as a SIGHUP that needs to be passed to their children? Or possibly even a patch such that when a controlling pty terminal is closed, all children (such as bash) reading from that pty get an end-of-input (possibly a SIGPIPE) when trying to read from the disappearing terminal? > Is there misconfiguration on my end or should I simply get in > the habit of always using exit to close rxvt? For now, that is the best course of action. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFWGwp84KuGfSFAYARAhoLAJ4mOFhGOWHcWVFqT1TUminyFF2/3wCgkWST Ibeyo2qq9zIyLaopU7CY3rM= =5ncP -END PGP SIGNATURE- -- 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: Bash process remains after I close rxvt in certain ways
Eric Lilja wrote: [snip] > Ok, no replies yet. I understand if people don't have the > solution/explanation at hand, but maybe someone else could try my rxvt > shortcut and say if he or she is seeing the same problem as I am? Yes, I can see the same problem if I close the window using the button. And the bash process stays waiting for input: $ ps PIDPPIDPGID WINPID TTY UIDSTIME COMMAND ... I 832 1 832 23842 1006 03:29:53 /usr/bin/bash -- René Berber -- 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: Bash process remains after I close rxvt in certain ways
Eric Lilja skrev: Hello, I never open the default cygwin "command window" anymore. Instead I use rxvt (a program I was introduced to after using cygwin for more than a year and I immediately fell in love with it). In my quicklaunch bar I have the following rxvt shortcut: C:\cygwin\bin\rxvt.exe -tn rxvt-cygwin-native -sr -sl 4000 -fn "Lucida Console-13" --background black --foreground white -geometry 145x40+10+0 -e bash --login -I I recently upgraded to a dual core machine which made me use the windows task manager alot. That's when I noticed that if I close the rxvt window by pressing 'x' in the top right corner (or doing alt-f4, I never do this, just tried it now to see what happened) the rxvt process is terminated and the window disappears but the "underlying" bash process is still running (without a visible window), consuming ~3.5 MB of memory and 0 cpu time according to the task manager. If I exit rxvt by typing exit, the bash process is terminated too. Can I do something so the bash process is always terminated properly no matter how I close the rxvt window? Is there misconfiguration on my end or should I simply get in the habit of always using exit to close rxvt? cygcheck.out attached. / E Ok, no replies yet. I understand if people don't have the solution/explanation at hand, but maybe someone else could try my rxvt shortcut and say if he or she is seeing the same problem as I am? / E Cygwin Configuration Diagnostics Current System Time: Sun Nov 12 20:39:19 2006 Windows XP Professional Ver 5.1 Build 2600 Service Pack 2 Path: C:\cygwin\usr\local\bin C:\cygwin\bin C:\cygwin\bin C:\cygwin\usr\X11R6\bin c:\WINDOWS\system32 c:\WINDOWS c:\WINDOWS\System32\Wbem c:\mingw32-make-3.81-1\bin c:\Program Files\IDM Computer Solutions\UltraEdit-32 c:\emacs\bin c:\Program Files\ATI Technologies\ATI.ACE\ c:\Program Files\Common Files\Teleca Shared Output from C:\cygwin\bin\id.exe (nontsec) UID: 1003(hivemind) GID: 513(None) 0(root) 513(None) 544(Administrators) 545(Users) Output from C:\cygwin\bin\id.exe (ntsec) UID: 1003(hivemind) GID: 513(None) 0(root) 513(None) 544(Administrators) 545(Users) SysDir: C:\WINDOWS\system32 WinDir: C:\WINDOWS USER = 'hivemind' PWD = '/home/hivemind' HOME = '/home/hivemind' MAKE_MODE = 'unix' HOMEPATH = '\Documents and Settings\hivemind' MANPATH = '/usr/local/man:/usr/share/man:/usr/man::/usr/ssl/man' APPDATA = 'C:\Documents and Settings\hivemind\Application Data' HOSTNAME = 'mindcooler' TERM = 'rxvt-cygwin-native' PROCESSOR_IDENTIFIER = 'x86 Family 15 Model 43 Stepping 1, AuthenticAMD' WINDIR = 'C:\WINDOWS' VS80COMNTOOLS = 'C:\vs8\Common7\Tools\' WINDOWID = '6830152' OLDPWD = '/usr/bin' USERDOMAIN = 'MINDCOOLER' OS = 'Windows_NT' ALLUSERSPROFILE = 'C:\Documents and Settings\All Users' DEFAULT_CA_NR = 'CA6' !:: = '::\' TEMP = '/cygdrive/c/DOCUME~1/hivemind/LOCALS~1/Temp' COMMONPROGRAMFILES = 'C:\Program Files\Common Files' USERNAME = 'hivemind' PROCESSOR_LEVEL = '15' FP_NO_HOST_CHECK = 'NO' SYSTEMDRIVE = 'C:' USERPROFILE = 'C:\Documents and Settings\hivemind' CLIENTNAME = 'Console' PS1 = '\[\e]0;[EMAIL PROTECTED] \[\e[33m\]\w\[\e[0m\]\n\$ ' LOGONSERVER = '\\MINDCOOLER' PROCESSOR_ARCHITECTURE = 'x86' SHLVL = '1' COLORFGBG = '15;default;0' PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH' HOMEDRIVE = 'C:' COMSPEC = 'C:\WINDOWS\system32\cmd.exe' TMP = '/cygdrive/c/DOCUME~1/hivemind/LOCALS~1/Temp' SYSTEMROOT = 'C:\WINDOWS' CVS_RSH = '/bin/ssh' PROCESSOR_REVISION = '2b01' INFOPATH = '/usr/local/info:/usr/share/info:/usr/info:' PROGRAMFILES = 'C:\Program Files' DISPLAY = ':0' NUMBER_OF_PROCESSORS = '2' SESSIONNAME = 'Console' COMPUTERNAME = 'MINDCOOLER' COLORTERM = 'rxvt-xpm' _ = '/usr/bin/cygcheck' POSIXLY_CORRECT = '1' HKEY_CURRENT_USER\Software\Cygnus Solutions HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2 HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2 (default) = '/cygdrive' cygdrive flags = 0x0022 HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/ (default) = 'C:\cygwin' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin (default) = 'C:\cygwin/bin' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib (default) = 'C:\cygwin/lib' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options c: hd NTFS 8Mb 41% CP CS UN PA FC d: cd CDFS 654Mb 100%CS UN CIV4WARLORDS C:\cygwin / system binmode C:\cygwin/bin /us
Bash process remains after I close rxvt in certain ways
Hello, I never open the default cygwin "command window" anymore. Instead I use rxvt (a program I was introduced to after using cygwin for more than a year and I immediately fell in love with it). In my quicklaunch bar I have the following rxvt shortcut: C:\cygwin\bin\rxvt.exe -tn rxvt-cygwin-native -sr -sl 4000 -fn "Lucida Console-13" --background black --foreground white -geometry 145x40+10+0 -e bash --login -I I recently upgraded to a dual core machine which made me use the windows task manager alot. That's when I noticed that if I close the rxvt window by pressing 'x' in the top right corner (or doing alt-f4, I never do this, just tried it now to see what happened) the rxvt process is terminated and the window disappears but the "underlying" bash process is still running (without a visible window), consuming ~3.5 MB of memory and 0 cpu time according to the task manager. If I exit rxvt by typing exit, the bash process is terminated too. Can I do something so the bash process is always terminated properly no matter how I close the rxvt window? Is there misconfiguration on my end or should I simply get in the habit of always using exit to close rxvt? cygcheck.out attached. / E Cygwin Configuration Diagnostics Current System Time: Sun Nov 12 20:39:19 2006 Windows XP Professional Ver 5.1 Build 2600 Service Pack 2 Path: C:\cygwin\usr\local\bin C:\cygwin\bin C:\cygwin\bin C:\cygwin\usr\X11R6\bin c:\WINDOWS\system32 c:\WINDOWS c:\WINDOWS\System32\Wbem c:\mingw32-make-3.81-1\bin c:\Program Files\IDM Computer Solutions\UltraEdit-32 c:\emacs\bin c:\Program Files\ATI Technologies\ATI.ACE\ c:\Program Files\Common Files\Teleca Shared Output from C:\cygwin\bin\id.exe (nontsec) UID: 1003(hivemind) GID: 513(None) 0(root) 513(None) 544(Administrators) 545(Users) Output from C:\cygwin\bin\id.exe (ntsec) UID: 1003(hivemind) GID: 513(None) 0(root) 513(None) 544(Administrators) 545(Users) SysDir: C:\WINDOWS\system32 WinDir: C:\WINDOWS USER = 'hivemind' PWD = '/home/hivemind' HOME = '/home/hivemind' MAKE_MODE = 'unix' HOMEPATH = '\Documents and Settings\hivemind' MANPATH = '/usr/local/man:/usr/share/man:/usr/man::/usr/ssl/man' APPDATA = 'C:\Documents and Settings\hivemind\Application Data' HOSTNAME = 'mindcooler' TERM = 'rxvt-cygwin-native' PROCESSOR_IDENTIFIER = 'x86 Family 15 Model 43 Stepping 1, AuthenticAMD' WINDIR = 'C:\WINDOWS' VS80COMNTOOLS = 'C:\vs8\Common7\Tools\' WINDOWID = '6830152' OLDPWD = '/usr/bin' USERDOMAIN = 'MINDCOOLER' OS = 'Windows_NT' ALLUSERSPROFILE = 'C:\Documents and Settings\All Users' DEFAULT_CA_NR = 'CA6' !:: = '::\' TEMP = '/cygdrive/c/DOCUME~1/hivemind/LOCALS~1/Temp' COMMONPROGRAMFILES = 'C:\Program Files\Common Files' USERNAME = 'hivemind' PROCESSOR_LEVEL = '15' FP_NO_HOST_CHECK = 'NO' SYSTEMDRIVE = 'C:' USERPROFILE = 'C:\Documents and Settings\hivemind' CLIENTNAME = 'Console' PS1 = '\[\e]0;[EMAIL PROTECTED] \[\e[33m\]\w\[\e[0m\]\n\$ ' LOGONSERVER = '\\MINDCOOLER' PROCESSOR_ARCHITECTURE = 'x86' SHLVL = '1' COLORFGBG = '15;default;0' PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH' HOMEDRIVE = 'C:' COMSPEC = 'C:\WINDOWS\system32\cmd.exe' TMP = '/cygdrive/c/DOCUME~1/hivemind/LOCALS~1/Temp' SYSTEMROOT = 'C:\WINDOWS' CVS_RSH = '/bin/ssh' PROCESSOR_REVISION = '2b01' INFOPATH = '/usr/local/info:/usr/share/info:/usr/info:' PROGRAMFILES = 'C:\Program Files' DISPLAY = ':0' NUMBER_OF_PROCESSORS = '2' SESSIONNAME = 'Console' COMPUTERNAME = 'MINDCOOLER' COLORTERM = 'rxvt-xpm' _ = '/usr/bin/cygcheck' POSIXLY_CORRECT = '1' HKEY_CURRENT_USER\Software\Cygnus Solutions HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2 HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2 (default) = '/cygdrive' cygdrive flags = 0x0022 HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/ (default) = 'C:\cygwin' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin (default) = 'C:\cygwin/bin' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib (default) = 'C:\cygwin/lib' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options c: hd NTFS 8Mb 41% CP CS UN PA FC d: cd CDFS 654Mb 100%CS UN CIV4WARLORDS C:\cygwin / system binmode C:\cygwin/bin /usr/bin system binmode C:\cygwin/lib /usr/lib system binmode . /cygdrive system binmode,cygdrive Found: C:\cygwin\bin\awk.exe Found: C:\cygwin\bin\bash.exe Found: C:\cygwin\bin\cat.exe Found: C:\cygwin\bin\cp.exe Found: C:\cygwin\bin\cpp.exe Not Found: crontab Found: C:\cygwin\bin\
