X-Spam-Check-By: sourceware.org
Message-Id: <1136300637.4061.250973784@webmail.messagingengine.com>
From: "Brett Serkez" <techie AT serkez DOT net>
To: "Eric Blake" <ebb9 AT byu DOT net>
Cc: cygwin AT cygwin DOT com
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="ISO-8859-1"
MIME-Version: 1.0
References: <1136145671 DOT 25904 DOT 250873783 AT webmail DOT messagingengine DOT com>    <43BA81DA DOT 8070009 AT byu DOT net>
Subject: Re: Hope this topic isn't taboo yet
In-Reply-To: <43BA81DA.8070009@byu.net>
Date: Tue, 03 Jan 2006 10:03:57 -0500
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

> > On the ZoneLabs message boards I found references to use of tcsh in
> > place of bash, that seems to work around the problem as follows:
> > 
> 
> I wonder what the difference is between bash and tcsh that gives rise to
> that idea.  Your choice of shell shouldn't affect your CPU usage; and if
> there is a bug in bash, I would like more details to help reproduce what
> it is.

I'm running Cygwin sshd on 35+ Windows desktops, it has to work reliably
and not interfere with normal system operation, I've not consistently
seen a specific way to reproduce, only that when it happens, the system
becomes almost unusable, especially if it is sshd.  

My sense of it is that it has something to do with process creation,
sometimes turning off security software (i.e. ZoneAlarm, CounterSpy and
the like relieves the issue).  This was re-enforced during my research
on the same behavior in sshd as the insight led me to my discovery that
by turning off the optional extra fork/exec, the problem was eliminted
there also.  It is also re-enforced by seeing how long it takes to start
a new shell, either via an xterm or the cygwin icon/script.  With bash,
it can sometimes take minutes, with tcsh, it is almost the blink of an
eye.  Again, turning off security software seems to make a difference
with bash, but a system cannot be run for more than experimenting in
that mode and I don't believe is the total issue.

UNIXies are geared towards creation of lots of small processes, I
believe security software 'gets involved' during process creation to
check for viruses, spyware, trojans and the like.

Lots of assumptions so far, the primary concern is simply keeping all
the systems stable, I can try to track down further as time allows.
 
> > 
> > - Modify individual scripts, as appropriate, and change the she-bang
> > line to: #!/bin/tcsh.
> 
> Whoa there - that usually doesn't work.  bash and tcsh have completely
> different ideas of syntax, and blindly changing the #! to a different
> shell is liable to lead to failure.

Yes, perhaps I should have elaborated here.  There maybe syntax issues
here between the shells, althought bash *tries* to be a superset to all
shells.  I've been lucky enough that any scripts I have are simple
enough to allow this to work, but you are correct, this will not work
with all/most scripts without rewriting.  But it does work well as a
login shell and significantly decreases the time it takes to open a new
shell.

This is an imperfect solution, but as you said, it does point to some
difference between tcsh and bash, my *guess* is in process creation or
related tasks, such as setup of signals, pipes, close of unused file
descriptors...  This is the area I had planned to look into in more
detail.

Brett
----------------------------------------------------------------
Brett C. Serkez, Techie



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