Opened 9 years ago
Closed 9 years ago
#1380 closed defect (fixed)
Missing environment with "display_win_gui=true"
Reported by: | dlove | Owned by: | Dave Love <d.love@…> |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | sge | Version: | 8.0.0c |
Severity: | minor | Keywords: | windows patch |
Cc: |
Description
From Thimo Neubauer.
http://arc.liv.ac.uk/pipermail/sge-discuss/2011-November/000190.html:
Hi! I've got a problem with Grid Engine on Windows hosts and wanted to check whether I'm missing something obvious or encountering a bug. What I'm experiencing is that the usual GE environment variables (including PE_HOSTFILE) aren't set when "-l display_win_gui=true" is set. You can see the effect when you qsub /dev/fs/C/Windows/System32/cmd.exe /c "set S > c:\env.txt" where "c:\env.txt" will contain all environment variables starting with "S". With "display_win_gui=true" I don't see a single SGE_* variable; without I get SGE_CELL, SGE_ARCH, etc. like I expected. I'm working with sources I've taken from darcs in June. Before upgrading to 8.0.0c I've decided to review the diff: nothing in there seems like fix to me. I've traced the sources so far as to understand that SGE_Helper_Service is used for the display_win_gui mode and that it constructs an environment for the process. However I don't understand the architecture enough to see how execd/shepherd pass information into the helper. My use case is a test of our Windows-GUI based application which can initiate MPI computations. Without PE_HOSTFILE I fail to see how I can find out which hosts I can use for the MPI run :)
Attachments (1)
Change History (6)
comment:1 Changed 9 years ago by aylee
comment:2 Changed 9 years ago by aylee
Following the example in
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682431%28v=vs.85%29.aspx
I've used CreateEnvironmentBlock? to inherit from the current environment. The attached patch works for me but certainly isn't the most elegant code I've ever written...
Lets see whether more surprises appear when I deploy the changed SGE_Starter.exe to our cluster...
comment:4 Changed 9 years ago by dlove
- Keywords patch added
SGE <sge-bugs@…> writes:
I've used CreateEnvironmentBlock? to inherit from the current environment.
The attached patch works for me but certainly isn't the most elegant code
I've ever written...
Lets see whether more surprises appear when I deploy the changed
SGE_Starter.exe to our cluster...
Thanks for that. I'll install it if you can confirm there weren't any
nasty surprises.
comment:5 Changed 9 years ago by aylee
Improved the patch a bit: before Windows set "HOME" to "/" which confused my subsequent code. This code works fine on our cluster.
comment:6 Changed 9 years ago by Dave Love <d.love@…>
- Owner set to Dave Love <d.love@…>
- Resolution set to fixed
- Status changed from new to closed
In [4143/sge]:
(The changeset message doesn't reference this ticket)
I've found the reason: in "display_win_gui=true" mode the job start goes from shepherd via SGE_Helper_Service.exe to SGE_Starter.exe. The helper service knows (and sets) the environment correctly but in SGE_Starter.cpp the call to spawn the executable
passes NULL as environment (the eigth parameter). Consequently the default user environment is used...