Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DEISA fork of modulecmd.tcl is missing a proper header/hashbang, which Tcl environment modules can't handle #733

Closed
boegel opened this issue Oct 23, 2013 · 5 comments

Comments

@boegel
Copy link
Member

boegel commented Oct 23, 2013

The DEISA fork of modulecmd.tcl, which is used on several big systems like JUROPA @ JSC, doesn't have a proper tclsh hashbang, which is causing problems when a command like modulecmd.tcl python load GCC/4.6.3 is being run via subprocess.Popen, which runs it in a bash shell by default.

For Tcl environment modules, any subprocess.Popen calls of modulecmd.tcl should be using the tclsh shell instead to dance around this problem.

@stdweird
Copy link
Contributor

@boegel can be easily fixed by defining the executable in run_cmd and passing it to the Popen call. also make this change for run_qa; and try to add a unit test for this (ie so something will break when using vsc.utils.run).

@fgeorgatos
Copy link
Collaborator

Hi,

I was sitting next to Alan when this issue emerged and,
if I recall correctly, the offer above fixes only half of the issue (ie. picking up the correct interpreter);
the other half would be to ensure that tclsh can pick modulecmd.tcl from the correct path
(ie. unlike bash, it does not iterate over $PATH to find it), so some extra fix is needed about it.

@ocaisa
Copy link
Member

ocaisa commented Oct 24, 2013

An example of the error in the unit tests:

======================================================================
ERROR: Make sure LD_LIBRARY_PATH is what it should be when loaded multiple modules.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/homeb/zam/ocaisa/.local/easybuild/lib/python2.6/site-packages/easybuild_framework-1.9.0dev-py2.6.egg/test/framework/modules.py", line 110, in 
test_LD_LIBRARY_PATH
    testmods.load(['GCC/4.6.3'])
  File "/homeb/zam/ocaisa/.local/easybuild/lib/python2.6/site-packages/easybuild_framework-1.9.0dev-py2.6.egg/easybuild/tools/modules.py", line 227, in
 load
    self.run_module('load', mod)
  File "/homeb/zam/ocaisa/.local/easybuild/lib/python2.6/site-packages/easybuild_framework-1.9.0dev-py2.6.egg/easybuild/tools/modules.py", line 311, in
 run_module
    proc = subprocess.Popen([self.cmd, 'python'] + args, stdout=PIPE, stderr=PIPE, env=environ)
  File "/usr/lib64/python2.6/subprocess.py", line 639, in __init__
    errread, errwrite)
  File "/usr/lib64/python2.6/subprocess.py", line 1228, in _execute_child
    raise child_exception
OSError: [Errno 8] Exec format error

@boegel
Copy link
Member Author

boegel commented Oct 26, 2013

This problem should fixed in #739 (which needs some more work to take @stdweird's suggestions into account); more work is needed to make EB play nicely with the DEISA modules though. That (old) version of modulecmd.tcl does some checks on $MODULEPATH, and barfs if you adjusting $MODULEPATH directly instead of using module use.

Passing the shell to the shell argument of Popen didn't work, because then I simply get no output (unclear why).
So, I just prefixed the command executed by Popen with tclsh (and specify modulecmd.tcl full path).

See #739 for the nasty details, it is still a work-in-progress, so comments on the code are welcome there.

@boegel
Copy link
Member Author

boegel commented Nov 1, 2013

fixed now #739 is merged in

@boegel boegel closed this as completed Nov 1, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants