Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com Message-ID: <39A5206F.15DD74F8@cygnus.com> Date: Thu, 24 Aug 2000 15:17:35 +0200 From: Corinna Vinschen X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.14-SMP i686) X-Accept-Language: de, en MIME-Version: 1.0 To: Chris Faylor CC: cygwin-developers AT sources DOT redhat DOT com Subject: Re: Any better now? References: <20000824000822 DOT A10979 AT cygnus DOT com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Chris Faylor wrote: > > I've checked in some patches to cygwin which fix inetd/telnet operation > for me. Do they work for you, Corinna? I haven't tried sshd yet. Unfortunately not. If sshd is started as service it wastes 100% CPU time. Very hard to kill since nearly no time for other processes. If sshd is started as foreground process from command line with debug option (== no fork) it seems to work but the client responds only to each second keypress. If started from the command line without debug option (forking the daemon, then exit of the parent): - The child gets forked but the parent never exits. - When pressing Ctrl-C, parent exits, child remains in background (which is ok since it has called setsid()). - It's impossible to get a client connection to the daemon. If started as background process from command line (sshd &) which isn't the default usage but the most interesting scenario: - The shell told me, PID of sshd is 484. - ps -el told me, there's only one sshd with PID = WINPID = 640 - Task-Manager told me, there are two sshds with WINPID's 120 and 640. - sshd wastes 100% CPU time, according to Task-Manager but for some reason there is enough CPU left to start other processes or to kill sshd within one second. - Killing the 640 process, the child (which is NOT in the cygwin process list! See above) remains running (which is again ok because of the setsid()). - It's impossible to get a connction to the daemon. Investigating the last two scenarios I could find that the 100% CPU time is used by the never ending parent process. Hope, that helps, Corinna