Description of problem:

If one runs oo-ruby when one has already run scl enable ruby193, oo-ruby does not set up the ruby193 scl environment correctly.

For example, if one runs a script A with the #!/usr/bin/env oo-ruby shebang, script A runs a script B that munges PATH, and script B then runs script C that again has the #!/usr/bin/env oo-ruby shebang, the invocation of oo-ruby in script C still has the munged path that script B set; scl enable does not reset PATH, LD_LIBRARY_PATH, etc.


Version-Release number of selected component (if applicable):

openshift-origin-util-scl-1.4.1-1.1.el6op.noarch
scl-utils-20120927-2.el6_4.6.x86_64


How reproducible:

Completely.


Steps to Reproduce:

1. printf '#!/usr/bin/env oo-ruby\nputs `/bin/b`\n' > /bin/a ; printf '#!/bin/sh\nexport PATH=/bin:/usr/bin\n/bin/c\n' > /bin/b ; printf '#!/usr/bin/env oo-ruby\nputs RUBY_VERSION\n' > /bin/c ; chmod 755 /bin/{a,b,c}

2. /bin/a


Actual results:

Step 1 creates the following files:

    # cat /bin/a
    #!/usr/bin/env oo-ruby
    puts `/bin/b`
    # cat /bin/b
    #!/bin/sh
    export PATH=/bin:/usr/bin
    /bin/c
    # cat /bin/c
    #!/usr/bin/env oo-ruby
    puts RUBY_VERSION

At Step 2, we see that /bin/a is running with the system Ruby interpreter (Ruby 1.8.7 in RHEL6):

    # /bin/a
    1.8.7
    #


Expected results:

At Step 2, we should see that /bin/a is running with the ruby193 scl's Ruby interpreter (Ruby 1.9.3):

    # /bin/a
    1.9.3
    #


Additional info:

The problem did not exist with scl-utils-20120927-2.el6.x86_64; it only appeared with scl-utils-20120927-2.el6.x86_64.

See bug 1016962, "scl enable does not set up the environment in a nested invocation." According to the scl-utils maintainer are using scl enable improperly.

The problem is related to the X_SCLS environment variable, which scl enable sets.

    # X_SCLS='ruby193 ' oo-ruby -v
    ruby 1.8.7 (2011-06-30 patchlevel 352) [x86_64-linux]
    # X_SCLS=' ' oo-ruby -v
    ruby 1.9.3p448 (2013-06-27) [x86_64-linux]

A workaround would be to unset X_SCLS in oo-ruby or oo-exec-ruby.

The problem is that scl enable sets an environment variable X_SCLS to
keep track of what software collections have been enabled, and it does
not set up the environment for a collection if that collection is
already in X_SCLS.

We ran into the problem when we run oo-admin-ctl-gears on OSE 1.2 with v1 cartridges when gears had .env/PATH files that did not include the ruby193 scl.  This problem with oo-admin-ctl-gears does not apply to Origin because v2 gears don't have .env/PATH and the cartridge script code that is running oo-get-mcs-level in the v1 cartridge model is superseded by the platform in the v2 cartridge model.

I do not know of a codepath in Origin or involving v2 carts the exhibits the bug.  However, for those who are curious how this bug plays out in OSE 1.2 with v1 cartridges, here is what happens:
 
1. /usr/sbin/oo-admin-ctl-gears has the #!/usr/bin/env oo-ruby shebang, which runs /usr/bin/oo-ruby, which runs /usr/bin/oo-exec-ruby, which essentially runs scl enable ruby193 "ruby $*", which sets the PATH variable so that we get the Ruby 1.9.3 interpreter.  The scl enable command also sets X_SCLS='ruby193 '.

2. oo-admin-ctl-gears goes to each cartridge of each gear and runs that cartridge's status script.

3. When executing the status script, the platform sources the gear's environment variables in .env/, including .env/PATH, which may not include /opt/rh/ruby193/root/usr/bin, and so we end up with a PATH that will get us the wrong Ruby interpreter (in particular, it will get us the Ruby 1.8.7 interpreter).

4. The status script calls setup_basic_hook, which calls setup_basic_vars, which calls setup_user_vars, which calls oo-get-mcs-level.

5. /usr/bin/oo-get-mcs-level has the #!/usr/bin/env oo-ruby shebang, which runs /usr/bin/oo-ruby, which runs /usr/bin/oo-exec-ruby, which essentially runs scl enable ruby193 "ruby $*", just like before; but this time, X_SCLS is already set to 'ruby193 ', and so scl enable does not set PATH.

6. Because scl enable does not set PATH, /usr/bin/oo-get-mcs-level runs with the wrong Ruby interpreter.