Subject: bash "pregnant pauses" revisited (B19 on NT 4.0)
From: [email-masked] (Arndt Schoenewald)

14 Aug 1998 06:54:04 -0700
Message-ID: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
To: [email-masked]
Cc: [email-masked]

[This is about a phenomenon already mentioned on the list. It seems
I have found a partial solution.]

Yesterday I downloaded and installed Cygwin32 B19 (for the first time,
i.e. I am new to Cygwin32) on a machine running Windows NT 4.0 Server
w/ SP3. Interestingly, I am seeing the same symptoms as described by
Andrew Sharp ([email-masked]) in a post to the gnu-win32 list:

> From: Andrew Sharp <[email-masked]>
> Subject: Re: Poor perf of cd; pregnant pauses
> Date: Mon, 20 Jul 1998 22:45:46 +0000 
> 
> A number of emails about this have come and gone in the last few days. 
> Here is my experience:  starting with 19.[01], almost any command can
> have a "pregnant pause" which occurrs after the command has exited but
> before bash prints the next prompt.  Or approximately in that frame of
> reference.  It is semi-random, however, and not confined to 'cd'
> commands.  The same command typed over and over will get the pause
> sometimes and sometimes not.  This on NT 4.0.
> ...

I can reproduce this problem easily and without any shell commands being
involved: when launching \Cygnus\B19\cygnus.bat, the window opens and
the text "Cygnus Cygwin32 B19" is printed almost immediately, but then
it takes a couple of seconds (around 7 seconds) before the bash prompt
appears. If I subsequently press <RETURN> a couple of times (i.e.,
no command entered), the prompt is reprinted instantly as one would
expect. But if I wait a while without using the shell and then press
<RETURN> again, it takes another 7 seconds before the prompt comes back.

I changed the cygwinb19.dll to 19.1 and then to 19.3 from the current
coolview package, but no effect.

Having some kind of feeling that this delay could be network related,
I started `snoop' on a Solaris machine on the same network, and found
that the following packets were sent during the delay periods:

    kilo.schoenewald.de -> 194.162.119.255 UDP D=137 S=137 LEN=58
    kilo.schoenewald.de -> 194.162.119.255 UDP D=137 S=137 LEN=58
    kilo.schoenewald.de -> 194.162.119.255 UDP D=137 S=137 LEN=58
    kilo.schoenewald.de -> 194.162.119.255 UDP D=137 S=137 LEN=58
    kilo.schoenewald.de -> 194.162.119.255 UDP D=137 S=137 LEN=58
    kilo.schoenewald.de -> 194.162.119.255 UDP D=137 S=137 LEN=58

(Port 137 belongs to the NETBIOS Name Service.)

I then went into the Network Properties and activated "Enable DNS for
Windows Resolution" in the "WINS Address" tab of the TCP/IP settings.
After the reboot, the bash delay was still the same, but in addition to
the packets listed below, the machine would also contact the DNS server
and ask for the address of "unknown.schoenewald.de" and then "unknown",
which didn't exist.

I then created %SYSTEMROOT%\system32\drivers\etc\LMHOSTS with

    123.45.67.89	unknown	#PRE

as the only contents. I used a bogus IP address which would be easy to
spot when bouncing off the firewall that protects my network, and made
sure "Enable LMHOSTS Lookup" was selected in the same TCP/IP property
sheet mentioned above (I also turned DNS resolution back off).

After a reboot, I found that the system would try to contact IP address
123.45.67.89 on port 139 (NETBIOS session service, used for accessing
network shares) when the bash executable was started.  As the packets
to 123.45.67.89 didn't go through, the bash process was hanging before
ever printing the prompt until I killed it.

I then changed %SYSTEMROOT%\system32\drivers\etc\LMHOSTS to

    127.0.0.1   	unknown	#PRE

rebooted, and voila, the prompt delay is now only 3 seconds (but
reoccurs every once in a while just as before).

The 3 seconds are definitely better than the 7 seconds I had before,
but still not satisfactory. I hope my description will ring a bell with
someone on this list so this problem can finally be fixed. What causes
these attempts to resolve and access "unknown"?

(No, I don't have any environment variables containing "unknown".)

Arndt

PS: Please keep me on copy as I am not subscribed to gnu-win32.

-- 
Arndt Schoenewald ([email-masked])
IT Technology & Solutions Integrator
Ostenhellweg 31, 44135 Dortmund, Germany
Tel: +49 231 556075
Fax: +49 231 556049
-
For help on using this list (especially unsubscribing), send a message to
"[email-masked]" with one line of text: "help".