Bash process remains after I close rxvt in certain ways

[Charles Wilson]

[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/