Bigtop
  1. Bigtop
  2. BIGTOP-479

init.d scripts should provide an option for initializing persistent state of the services that require it

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 0.4.0
    • Fix Version/s: 0.4.0
    • Component/s: general
    • Labels:
      None

      Description

      The following services require an explicit initialization of the persistent state in the local filesystem:

      1. Hadoop NameNode (formatting a namenode via: hdfs namenode -format)
      2. ZooKeeper (formatting a local storage area via: zookeeper-server-initialize)

      and the following ones require an initialization of the RDBMS database (which can reside on a local filesystem
      via Derby or be hosted on a remote server such as Postgress, MySQL, Oracle, etc.):

      1. oozie DB (initialized via ooziedb.sh)
      2. possible Hive metastore
      3. possibly Sqoop metastore

      In order to free the user from an explicit knowledge of what command to run under which account it is desirable
      to have an init.d scripts for the above components support and extra command called 'init'.

      Please let me know what do you all think.

      1. BIGTOP-479.patch.txt
        3 kB
        Roman Shaposhnik

        Activity

        Hide
        Bruno Mahé added a comment -

        +1 for the patch.

        I also agree with James, but for now we don't have yet neither systemd nor upstart scripts. And given that this patch is quite small, I don't see any issue moving this somewhere else when needed.

        Show
        Bruno Mahé added a comment - +1 for the patch. I also agree with James, but for now we don't have yet neither systemd nor upstart scripts. And given that this patch is quite small, I don't see any issue moving this somewhere else when needed.
        Hide
        Roman Shaposhnik added a comment -

        James, I agree with your general comment, but the question is – what's the proper place to put the code that is supposed to su into the same user account that the daemons are running under? init.d scripts already know what that user account is (since they do the sudo to begin with) and it looks like nothing else does.

        To take a step back – we do provide wrappers for all of that init'ing, but they need to be run as follows:

          sudo -u <UID> <init-wrapper> <init-wrapper args>
        

        I would like to hide the complexity of 'sudo -u <UID>' and <init-wrapper args> from the user and would appreciate suggestions on what the proper place for that would be.

        For now, I'm attaching a patch for existing init.d scripts. We can always move that code to some other place.

        Show
        Roman Shaposhnik added a comment - James, I agree with your general comment, but the question is – what's the proper place to put the code that is supposed to su into the same user account that the daemons are running under? init.d scripts already know what that user account is (since they do the sudo to begin with) and it looks like nothing else does. To take a step back – we do provide wrappers for all of that init'ing, but they need to be run as follows: sudo -u <UID> <init-wrapper> <init-wrapper args> I would like to hide the complexity of 'sudo -u <UID>' and <init-wrapper args> from the user and would appreciate suggestions on what the proper place for that would be. For now, I'm attaching a patch for existing init.d scripts. We can always move that code to some other place.
        Hide
        James Page added a comment -

        I think having helpers that do this is useful - but I don't think the init script is the correct place todo this.

        Rationale: if users want to use upstart or systemd in the future we don't really have the option to have an extra command for 'init' as they work in a different way.

        Show
        James Page added a comment - I think having helpers that do this is useful - but I don't think the init script is the correct place todo this. Rationale: if users want to use upstart or systemd in the future we don't really have the option to have an extra command for 'init' as they work in a different way.

          People

          • Assignee:
            Roman Shaposhnik
            Reporter:
            Roman Shaposhnik
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development