Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Delivered-To: mailing list cygwin@cygwin.com Date: Fri, 26 Dec 2003 21:40:10 -0500 From: Christopher Faylor To: cygwin@cygwin.com Subject: Re: Please try the latest snapshot -- it is close to cygwin 1.5.6 Message-ID: <20031227024010.GB25085@redhat.com> Mail-Followup-To: cygwin@cygwin.com References: <20031226204641.GA46362839@hpn5170x> <20031224152951.GA34487383@hpn5170x> <20031223222816.GA23935@redhat.com> <20031224152951.GA34487383@hpn5170x> <3.0.5.32.20031224181524.007c21c0@incoming.verizon.net> <20031224232759.GA12748@redhat.com> <20031226204641.GA46362839@hpn5170x> <3.0.5.32.20031226211336.00804140@incoming.verizon.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3.0.5.32.20031226211336.00804140@incoming.verizon.net> User-Agent: Mutt/1.4.1i X-IsSubscribed: yes Reply-To: cygwin@cygwin.com On Fri, Dec 26, 2003 at 09:13:36PM -0500, Pierre A. Humblet wrote: >At 05:59 PM 12/26/2003 -0500, Christopher Faylor wrote: >>I added strace debugging. You can use that as a clue for what I was >>talking about and make it visible if you can't run exim under strace. > >I put a try_to_debug(1). Waiting for something to happen. Thanks, for debugging this but that wasn't specifically what I was talking about. If you go back and read the message, you'll see that I was talking about your 'get_proc_lock' problem. >>>Also, while running sysinternals I noticed to the exim daemon still had tty >>>related handles, despite setsid(). Ditto for inetd. >> >>Calling setsid does not automatically eliminate tty handles. > >This is what inetd does: > if (setsid() == -1) > return (-1); > > if (!noclose && (fd = open(PATH_DEVNULL, O_RDWR, 0)) != -1) { > (void)dup2(fd, STDIN_FILENO); > (void)dup2(fd, STDOUT_FILENO); > (void)dup2(fd, STDERR_FILENO); >******* >Before your last changes, strace was showing > 160 282749 [main] inetd 34569887 close: close (2) > 361 283110 [main] inetd 34569887 fhandler_tty_slave::close: decremented open_fhs 0, archetype usecount 2 > 198 283308 [main] inetd 34569887 fhandler_tty_slave::close: just exiting because archetype usecount is > 0 > 163 283471 [main] inetd 34569887 close: 0 = close (2) > 160 283631 [main] inetd 34569887 dtable::dup2: 2 = dup2 (3, 2) >******* > >Now usecount is even higher > > 159 292878 [main] inetd 1086339 close: close (2) > 181 293059 [main] inetd 1086339 fhandler_tty_slave::close: decremented open_fhs 0, archetype usecount 3 > 313 293372 [main] inetd 1086339 fhandler_tty_slave::close: just returning because archetype usecount is > 0 > 175 293547 [main] inetd 1086339 close: 0 = close (2) > 158 293705 [main] inetd 1086339 dtable::dup2: 2 = dup2 (3, 2) > > >I looked at your latest change in syscalls.cc. >It seems to me that setsid should simply call close all the time if (cygheap->ctty) >and let close() take care of usecount. I had already checked in a change to this effect but I missed... >Ditto in pinfo::set_ctty where a problem similar to the one you >addressed also exists. this. Thanks. I've checked in a new fix as well as a similar change for close_all_files. >I don't think that will take care of everything, but I can't follow >what's happening when tracing sh -c inetd I tried the current CVS version and I don't see any stray tty garbage with inetd. I never tried this with an older snapshot, however, so I don't know if I would have been lucky before. I did try a much simpler test case which worked incorrectly with CYGWIN=tty and correctly after today's initial setsid change. 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/