On Oct 29 18:13, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
> > platforms expect /bin and/or /usr/bin to be in your path
>
> I'm not following... cygrunsrv.exe is started by Windows service controller,
> and then spawns the server binary. There's no point in this sequence of
> actions
> to modify PATH. I also believe, PATH is made compliant with what POSIX
> requirement
> by that very cygwin1.dll implicitly (and that happens when cygrunsrv gets
> launched,
> so cygwin1.dll figures out the CYGWIN "root" directory, then evaluates the
> path where
> to expect all other CYGWIN dlls). For cygrunsrv, the server binary is
> specified as an
> absolute path with -p "/opt/path/to/bin/server.exe", which is within the
> rudimentary
> CYGWIN tree that also has "/bin" (rooted at some Windows directory,
> C:\Apps\CYGWIN).
>
> > 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.
> >
>
> Without chdir("/") fork() is able to succeed; and the server binary does not
> depend on any other non-Windows DLLs that are not in the "/bin" CYGWIN
> directory.
>
> But with chdir("/") in place, if I insert (when manually simulating the very
> same
> failure from a limited user account) "C:\Apps\CYGWIN\bin" into Windows PATH
> before
> calling the server binary, it is able to fork successfully. (Without the
> addition,
> it fails same way with the same error 0xC00000135 even when run
> interactively.)Hmm, on second thought, this could be a problem in cygrunsrv. I have a hunch what the problem might be. Are you running 32 or 64 bit Cygwin? If that's ok with you, I'd PM you an URL to a matching, patched cygrunsrv binary for testing. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
pgp6TK5GZbcIB.pgp
Description: PGP signature
