Bigtop
  1. Bigtop
  2. BIGTOP-945

Service lock files need to match init script name

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 0.6.0
    • Component/s: None
    • Labels:
      None

      Description

      The base name of the lock file created by init scripts needs to base name of the init script itself, because services are only shutdown if their lock file is present. Currently the Hadoop services do not have matching init scripts and lock files.

      This is not a problem in the recent patches to move Sqoop, Hive and HBase to similar templates, but it shouldn't be overridable in the .svc files. The template should enforce any system-specific LOCKDIR locations and ensure the outputted init script has the same name as the lockfile.

        Activity

        Hide
        Roman Shaposhnik added a comment -

        +1 and commited!

        Show
        Roman Shaposhnik added a comment - +1 and commited!
        Hide
        Sean Mackrory added a comment -

        Here's a better patch. It's consistent for all the services, and works for all the ones I tested (so far, HBase, Hive, Sqoop, HDFS).

        Show
        Sean Mackrory added a comment - Here's a better patch. It's consistent for all the services, and works for all the ones I tested (so far, HBase, Hive, Sqoop, HDFS).
        Hide
        Sean Mackrory added a comment -

        >> how removing LOCKDIR="/var/lock/subsys" from Sqoop, Hive and HBase would work?

        Since all services should have a matching service name and lock file, the template will just re-use the service name for the lockfile no .svc file should be trying to override it.

        >> why the asymmetric patch for all the hadoop daemons?

        I remember thinking there was a reason not to do the same in the hadoop template, but not only do I not recall what it was, it just dawned on me that the shared template is going to be overwriting Hadoop's template anyway, so they might as well be using it the same way. Will update the patch (and if I remember the reason, I'll update the comment ) and re-test...

        Show
        Sean Mackrory added a comment - >> how removing LOCKDIR="/var/lock/subsys" from Sqoop, Hive and HBase would work? Since all services should have a matching service name and lock file, the template will just re-use the service name for the lockfile no .svc file should be trying to override it. >> why the asymmetric patch for all the hadoop daemons? I remember thinking there was a reason not to do the same in the hadoop template, but not only do I not recall what it was, it just dawned on me that the shared template is going to be overwriting Hadoop's template anyway, so they might as well be using it the same way. Will update the patch (and if I remember the reason, I'll update the comment ) and re-test...
        Hide
        Roman Shaposhnik added a comment -

        Here's a few things I don't understand

        1. how removing LOCKDIR="/var/lock/subsys" from Sqoop, Hive and HBase would work?
        2. why the asymmetric patch for all the hadoop daemons?
        Show
        Roman Shaposhnik added a comment - Here's a few things I don't understand how removing LOCKDIR="/var/lock/subsys" from Sqoop, Hive and HBase would work? why the asymmetric patch for all the hadoop daemons?
        Hide
        Sean Mackrory added a comment -

        This fixes the Hadoop .svc files, and enforces the behavior in the new templates so everything else will be fixed once they migrate.

        Show
        Sean Mackrory added a comment - This fixes the Hadoop .svc files, and enforces the behavior in the new templates so everything else will be fixed once they migrate.

          People

          • Assignee:
            Sean Mackrory
            Reporter:
            Sean Mackrory
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development