On Oct 29 13:15, Larry Hall (Cygwin) wrote:
> On 10/29/2013 12:13 PM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
> >Hello All,
> >
> >I can't find a similar problem reported earlier, so please excuse the
> >question
> >if it looks familiar.
> >
> >We have a software package that installs like a miniature CYGWIN deployment
> >(basically, only cygwin1.dll and just a few other libraries in /bin
> >along with cygrunsrv.exe), and there are no shells.
> >
> >cygrunsrv.exe is used to register and launch a Windows service with a binary
> >located under "/opt/..." (which is a ported UNIX server). The binary is
> >started
> >just fine, but when it tries to fork(), it gets the error 0xC0000135 (w/
> >errno=11,
> >EAGAIN). I traced it down to the fact that before fork() there is
> >chdir("/") in
> >that server binary. Can it be the reason for the failed fork() that it can
> >no longer
> >find cygwin1.dll? Unfortunately, I can't extend Windows PATH to include the
> >CYGWIN /bin directory (because the cygrunsrv runs under an unmanaged service
> >account). Is there any other fix?
>
> I'll go out on a limb and say that all UNIX/POSIX platforms expect /bin
> and/or /usr/bin to be in your path if you're not specifying an absolute
> path when invoking your binaries. This is not an unusual expectation
> and isn't confined to the UNIX/POSIX world. There isn't any "fix" that
> will be forthcoming in the Cygwin DLL that will change this expectation,
> though there may be others on this list that have some clever workarounds
> that you could try.Two points: - cygrunsrv adds /bin to $PATH before calling the service executable. - STATUS_DLL_NOT_FOUND does *not* imply that cygwin1.dll isn't found. It could be any other DLL required by the executable but not in $PATH. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
pgpPOZNVf0J1Q.pgp
Description: PGP signature
