Details

    • Type: Sub-task Sub-task
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 0.2.0
    • Fix Version/s: 0.2.0
    • Component/s: Debian, General, RPM
    • Labels:
      None

      Activity

      Gavin made changes -
      Workflow no-reopen-closed, patch-avail [ 12639664 ] patch-available, re-open possible [ 12665856 ]
      Bruno Mahé made changes -
      Status Resolved [ 5 ] Closed [ 6 ]
      Bruno Mahé made changes -
      Status Patch Available [ 10002 ] Resolved [ 5 ]
      Resolution Fixed [ 1 ]
      Hide
      Roman Shaposhnik added a comment -

      Indeed! Silly me – goes to fetch a strong cup of Joe to start thinking straight

      +1

      Show
      Roman Shaposhnik added a comment - Indeed! Silly me – goes to fetch a strong cup of Joe to start thinking straight +1
      Hide
      Bruno Mahé added a comment - - edited

      wait, we are arguing for nothing.
      if JAVA_HOME is already defined, nothing will be auto-detected.
      See:
      > if [ -z "$JAVA_HOME" ]; then

      Show
      Bruno Mahé added a comment - - edited wait, we are arguing for nothing. if JAVA_HOME is already defined, nothing will be auto-detected. See: > if [ -z "$JAVA_HOME" ]; then
      Hide
      Bruno Mahé added a comment -

      from a very quick look, I haven't seen any easy way to set environment variable system wide for non login shells.

      For the commands such as pig or hbase shell, the links cited above would work. And for the service scripts, the java home autodetection is already done after the sourcing of default files, which should cover your use case.
      And also most projects make it possible to define JAVA_HOME in their <component>-config.sh.

      Show
      Bruno Mahé added a comment - from a very quick look, I haven't seen any easy way to set environment variable system wide for non login shells. For the commands such as pig or hbase shell, the links cited above would work. And for the service scripts, the java home autodetection is already done after the sourcing of default files, which should cover your use case. And also most projects make it possible to define JAVA_HOME in their <component>-config.sh.
      Hide
      Bruno Mahé added a comment -

      What I am referring to is only available in login shells. Let me look into it for non-login shells

      Show
      Bruno Mahé added a comment - What I am referring to is only available in login shells. Let me look into it for non-login shells
      Show
      Bruno Mahé added a comment - 1. See https://help.ubuntu.com/community/EnvironmentVariables#Persistent_environment_variables and more precisely https://help.ubuntu.com/community/EnvironmentVariables#System-wide_environment_variables
      Hide
      Roman Shaposhnik added a comment -

      Looks good. Lets address #1 and it should be good to go.

      Show
      Roman Shaposhnik added a comment - Looks good. Lets address #1 and it should be good to go.
      Bruno Mahé made changes -
      Hide
      Bruno Mahé added a comment -

      Here is a patch to apply on top of the previous one. It addresses 2.

      Show
      Bruno Mahé added a comment - Here is a patch to apply on top of the previous one. It addresses 2.
      Hide
      Roman Shaposhnik added a comment -

      #1 I feel uncomfortable about users not being able to override the results of our JAVA_HOME detection for init.d scripts. Please suggest a different place for them to put JAVA_HOME=XXX

      Show
      Roman Shaposhnik added a comment - #1 I feel uncomfortable about users not being able to override the results of our JAVA_HOME detection for init.d scripts. Please suggest a different place for them to put JAVA_HOME=XXX
      Hide
      Bruno Mahé added a comment -

      1. Defining JAVA_HOME in /etc/default/<component> would be the wrong place to do it

      2. I meant to source the hbase default file, but forgot to add it. Preparing another patch

      Show
      Bruno Mahé added a comment - 1. Defining JAVA_HOME in /etc/default/<component> would be the wrong place to do it 2. I meant to source the hbase default file, but forgot to add it. Preparing another patch
      Hide
      Roman Shaposhnik added a comment -

      1. I would like to keep a pattern where we source anything in /etc/default/* AFTER the JAVA_HOME auto-detection. That way, a user can override any decisions made by our java detection code.
      2. Why are we removing HBASE_PID_DIR ?

      Show
      Roman Shaposhnik added a comment - 1. I would like to keep a pattern where we source anything in /etc/default/* AFTER the JAVA_HOME auto-detection. That way, a user can override any decisions made by our java detection code. 2. Why are we removing HBASE_PID_DIR ?
      Bruno Mahé made changes -
      Status Open [ 1 ] Patch Available [ 10002 ]
      Bruno Mahé made changes -
      Field Original Value New Value
      Attachment 0001-BIGTOP-175.-All-of-HBase-wrapper-scripts-and-init.d-.patch [ 12500940 ]
      Bruno Mahé created issue -

        People

        • Assignee:
          Bruno Mahé
          Reporter:
          Bruno Mahé
        • Votes:
          0 Vote for this issue
          Watchers:
          0 Start watching this issue

          Dates

          • Created:
            Updated:
            Resolved:

            Development