Bash process remains after I close rxvt in certain ways

Wed Dec 6 09:00:00 GMT 2006

[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
 cwilson 3796 1 con 01:22:47 /usr/bin/rxvt
 cwilson 392 3796 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/