Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
To: cygwin AT cygwin DOT com
Path: not-for-mail
From: Andrew DeFaria <Andrew AT DeFaria DOT com>
Newsgroups: gmane.os.cygwin
Subject: Re: Error: "... sync_with_child ..." using scripts on WinNT 4 SP6
Date: Thu, 21 Feb 2002 13:23:16 -0800
Organization: Salira Optical Networks
Lines: 86
Message-ID: <3C756544.80504@DeFaria.com>
References: <3C75238A DOT D386501F AT conti DOT de>
NNTP-Posting-Host: 206.184.204.2
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
NNTP-Posting-Date: 21 Feb 2002 21:24:21 GMT
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1

Matthias Steppuhn wrote:

> Hello,
> I have been using shell scripts under cygwin a while ago with out any
> problem.
> Today I wanted to use one script again, but an error occured. I alreaded
> installed
> the most recent cygwin-files. It did not really help me. Using a
> different PC braught
> a very simmilar result.
> 
> The script is using a "normal" rsh-call:
>             rsh    -l     myuser    myhost    ls -ltr
> 
> When I type it on interactive shell it works perfect, but used in a
> script I only receive.
> 8<------------------------------->8
> 0 [main] rsh 329 sync_with_child: child 260(0x138) died before
> initialization with status code 0x18B00
> 316 [main] rsh 329 sync_with_child: *** child state child loading dlls
> /bin/rsh: fork: Resource temporarily unavailable
> 8<------------------------------>8
> Using cygcheck in front of the "rsh" tells me:
> 8<-------------------->8
> C:\cygwin\bin\rsh.exe
>   C:\cygwin\bin\cygwin1.dll
>     C:\WINNT\System32\KERNEL32.dll
>       C:\WINNT\System32\ntdll.dll
> 8<-------------------->8
> 
> Does anyone have an idea what might be wrong or where to read something
> that helps me

We've been having similar problems. Assuming it's actually a resource 
problem we've been pointed to the following MS articles:

Q142676: Overcoming User32.dll Initialization Failure Errors
(http://support.microsoft.com/support/kb/articles/Q142/6/76.ASP)
Q184802: INFO: User32.dll or Kernel32.dll Fails to Initialize
(http://support.microsoft.com/support/kb/articles/Q184/8/02.ASP)
Q169321: INFO: COM Servers Activation and NT Windows Stations
(http://support.microsoft.com/support/kb/articles/Q169/3/21.ASP)

According to Microsoft the memory is allocated where SharedSection 
specifies the system and desktop heaps using the following format:

SharedSection=xxxx,yyyy,zzzz where xxxx defines the maximum size of the
system-wide heap (in kilobytes), yyyy defines the size of the per 
desktop heap and zzzz defines non-intreactive desktop heap size.

NOTE: There is the possibilty of a fourth value: 
SharedSection=xxxx,yyyy,zzzz,aaaa The value aaaa is related to Windows 
Terminal Services heap size.

The first SharedSection value (1024) defines the heap size common to all
desktops. This includes the global handle table (Window handles are 
unique machine wide) and shared system settings (such as SystemMetrics). 
It is unlikely you would ever need to change this value.

The second SharedSection value (3072) controls the size of the desktop 
heap (used for Windows objects). This static value is used to prevent 
ill-behaved applications from consuming too many resources. Because the 
desktop heap is mapped into each process' address space, this value 
should not be set to an arbitrarily high value (as it would decrease 
performance), but should only be increased sufficiently to allow all the 
desired applications to run.

The third value defines the desktop heap size for non-interactive 
desktops (e.g. services). The default value was 3072 under NT 4.0 which 
equates to 3MB. Setting this value to 512 will allow approximately 90 
services or non-interactive desktop processes.

RESOLUTION:
1. Please read the above KB articles carefully.
2. Then use the regedit (or regedt32) to edit
"HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems".

Select the value Windows and change "SharedSection=1024,3072,512" to
"SharedSection=1024,3072,2048", then reboot. (The last value can be 
larger than 2048 depending on how many VOB/views they have on the machine.)

Sort of stands to reason since inetd and in.rsh.d are effectively 
service processes that do not have desktop presence thus they are 
probably using the other heap. Perhaps these programs still have memory 
leaks.


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/