Bug 1017248 - oo-ruby does not set up the correct environment in a nested invocation
oo-ruby does not set up the correct environment in a nested invocation
Status: CLOSED EOL
Product: OpenShift Origin
Classification: Red Hat
Component: Pod (Show other bugs)
2.x
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Abhishek Gupta
libra bugs
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-09 09:42 EDT by Miciah Dashiel Butler Masters
Modified: 2017-01-25 01:39 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-01-25 01:39:03 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Miciah Dashiel Butler Masters 2013-10-09 09:42:56 EDT
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.
Comment 1 Miciah Dashiel Butler Masters 2013-10-09 10:42:19 EDT
Pull request with the suggested workaround:   https://github.com/openshift/origin-server/pull/3815
Comment 2 Miciah Dashiel Butler Masters 2014-02-11 23:29:15 EST
Second attempt: https://github.com/openshift/origin-server/pull/4742
Comment 3 openshift-github-bot 2014-02-24 15:48:16 EST
Commit pushed to master at https://github.com/openshift/origin-server

https://github.com/openshift/origin-server/commit/4e58b817443840fa8d9c2dad55278d3116fc4db3
oo-exec-ruby: Set PATH &c. directly, not using scl

oo-exec-ruby: Set the PATH and LD_LIBRARY_PATH variables using straight
Bash code rather than using the scl command.

The OpenShift node platform munges PATH in some places, and a nested scl
invocation will not update the variables.  This fix is necessary so that
when we run oo-exec-ruby, munge PATH, and then run oo-exec-ruby, we get the
ruby193 scl back in the PATH.

This commit fixes bug 1017248.

Note You need to log in before you can comment on or make changes to this bug.