Forum OpenACS Development: Re: NaviServer 4.99: Issues with "rename"?

12: Re: NaviServer 4.99: Issues with "rename"? (response to 11)

Posted by Maurizio Martignano on 04/09/17 05:17 PM

Dear Gustaf and Frank,
I will try to explain the current situation for the Windows port (at least my installer).

1. the renaming was implemented in an old file "acs-tcl\tcl\windows-procs.tcl".

2. At least in my distribution that file is disabled, by calling it "windows-procs.tcl.org".

3. So my distribution uses the standard "exec" (when the nsproxy module is not loaded, that is
ns_section ns/server/${server}/modules
ns_param nssock ${bindir}/nssock.dll
# ns_param nsproxy ${bindir}/nsproxy.dll
)

4. with this configuration, running for instance the command:

exec psql -U postgres -l

5. the nsproxy module only recently (yesterday) got compilable under Windows and it is available in my distribution from today. With that module loaded, that is:
ns_section ns/server/${server}/modules
ns_param nssock ${bindir}/nssock.dll
ns_param nsproxy ${bindir}/nsproxy.dll
the same psql command given in the ds shell produces the following output:
ERROR:
exec failed: no such file or directory
while executing
"ns_proxy get ExecPool"
(procedure "::nsf::procs::proxy::exec" line 3)
invoked from within
"proxy::exec -call $args"

In fact also nsproxy renames the original exec.

Hope it helps,
Maurizio

13: Re: NaviServer 4.99: Issues with "rename"? (response to 12)

Posted by Gustaf Neumann on 04/09/17 08:18 PM

Dear Maurizio,

i have yesterday invested time to write the additional code to make the nsproxy module compile under windows. Support for nsproxy for win has been requested in the past several times. However, as i wrote in my mail to you, i've just invested time to implement the missing functions under windows, but i did not dig into the nmake logic to produce the binaries, so i asked you to test it....

The error message "no such file or directory" might indicate, that there is no nsproxy binary in the naviserver bin directory. Under windows, there should be a nsproxy.exe and a nsproxy.dll. Do you have these?

The "exec" definition in OpenACS does not rename "exec", but it overloads it. That makes it problematic, if one tries to rename it in addition.

14: Re: NaviServer 4.99: Issues with "rename"? (response to 13)

Posted by Maurizio Martignano on 04/10/17 09:36 AM

Dear Gustaf,
I believe we are talking in circles.
You wrote:
"Under windows, there should be a nsproxy.exe and a nsproxy.dll. Do you have these?".
The only important outputs of the Windows build process are nsd.exe and all modules *.dll files.
Executables like nssock.exe, or nsproxi.exe, etc.. are the intermediate build products created/used by the legacy nmake "makefiles".
And of course I had the nsproxy.dll in place. When you specify in the config file that you need to load a module (a *.dll) if it doesn't find it, it complains.
You also wrote
"The "exec" definition in OpenACS does not rename "exec", but it overloads it. That makes it problematic, if one tries to rename it in addition".
What I can see in the files is that both windows-procs.tcl (line 22) and proxy-procs.tcl (line 40) call a rename.
And what I can say is the following:
1. in my configuration/installer I do not load the windows-procs.tcl file, so that renaming does not take place.
2. when I use the system without loading nsproxy.dll the exec command works and looks for binaries in the specified PATH.
3. when I use the system with nsproxy.dll loaded the exec command does not work (and a renaming takes place).
4. Frank does not need nsproxy, I mean in the context of this discussion. He only needs a "new" exec to have control on where the system looks for binaries. So he can probably take the "new" exec in the windows-procs.tcl and modify it as he requires/pleases.

Hope it helps,
Maurizio

15: Re: NaviServer 4.99: Issues with "rename"? (response to 14)

Posted by Gustaf Neumann on 04/10/17 10:40 AM

Maurizio: The only important outputs of the Windows build process are nsd.exe and all modules *.dll files.

If this is the case, the windows build is incomplete. In an installation including nsproxy, there should be three binaries in the ns/bin directory:
- ns/bin/nsd.exe
- ns/bin/nsproxy.exe
- ns/bin/nsthreadtest.exe
On unixoid platforms the filename do not contain the .exe suffix. The last one is for testing.

It should not be complicated to produce an nsproxy executable under windows. As a reference, the nsproxy executable program is linked as follows:

gcc -L../nsthread -L../nsd -L../nsdb -o nsproxy  nsproxy.o libnsproxy.dylib -lnsthread -lnsd -L/usr/local/ns/lib -ltcl8.6     -prebind -headerpad_max_install_names -Wl,-search_paths_first  -L/usr/local/ns/lib -L/opt/local/lib -lssl -lcrypto

The nmake-file for windows should be extended to contain a similar build rule.

Concerning the "renaming" issues: Where are windows-procs.tcl coming from? This is not part of OpenACS. I was talking about OpenACS, where "exec" is redefined in acs-tcl/tcl/proxy-procs.tcl

There are certainly many ways to address to "exec" problem in Frank's case. My recommendation is to stay away from renaming and to aim for a solution, which is as close as possible to the maintained part of OpenACS. The advantages of nsproxy (probably incomplete)
- when nsproxy workers are started early, no memory bloat on execs (important, when running on machines with little memory)
- address the race-conditions, when a tcl script changes the working directory and issues a command in this directory
- allows to specify environment variables for the exec environment that can be different to those of the main process
- allows to set timeouts and many more to improve resiliance

But maybe, it is not worth the effort to get nsproxy running under windows.

16: Re: NaviServer 4.99: Issues with "rename"? (response to 15)

Posted by Frank Bergmann on 04/10/17 11:27 AM

Hi!

Short update: We are on the way to replace all exec ocurrences in ]po[ with "im_exec", which will include the Windows specific logic. So there is no "rename" anymore.

So I have moved the content from acs-tcl/tcl/windows-procs.tcl into this im_exec routine.

im_exec in turn calls exec, after some transformations of the arguments into a format that works with CygWin.

Cheers,
Frank