From: arndt AT schoenewald DOT de (Arndt Schoenewald) Subject: bash "pregnant pauses" revisited (B19 on NT 4.0) 14 Aug 1998 06:54:04 -0700 Message-ID: <19980813191637.63985.cygnus.gnu-win32@riga.schoenewald.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii To: gnu-win32 AT cygnus DOT com Cc: andy AT accrue DOT com [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 (andy AT accrue DOT com) in a post to the gnu-win32 list: > From: Andrew Sharp > 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 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 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 (arndt AT schoenewald DOT de) 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 "gnu-win32-request AT cygnus DOT com" with one line of text: "help".