Opened 13 years ago

Closed 9 years ago

#601 closed defect (fixed)

IZ2807: inadequate inst_qmaster/inst_execd diagnosis if binary and common packages are not in $SGE_ROOT

Reported by: mpospisil Owned by:
Priority: normal Milestone:
Component: sge Version: 6.0
Severity: minor Keywords: install

Description (last modified by admin)

[Imported from gridengine issuezilla]

        Issue #:      2807             Platform:     All      Reporter: mpospisil (mpospisil)
       Component:     gridengine          OS:        All
     Subcomponent:    install          Version:      6.0         CC:    None defined
        Status:       NEW              Priority:     P3
      Resolution:                     Issue type:    DEFECT
                                   Target milestone: ---
      Assigned to:    mpospisil (mpospisil)
      QA Contact:     dom
       * Summary:     inadequate inst_qmaster/inst_execd diagnosis if binary and common packages are not in $SGE_ROOT
   Status whiteboard:

     Issue 2807 blocks:
   Votes for issue 2807:

   Opened: Fri Nov 21 08:13:00 -0700 2008 

The current SGE installation is designed to require SGE_ROOT pointing to the
root directory of the distribution and to be the parent directory of the <cell>

I suspect that the inadequate error checking was introduced with SGE 6.0! The
SGE 5.3 checked by default if this prerequsite is met.

The SGE 5.3 installation routine has a function which is called
"ProcessQsystRoot". In this shell function by default there is a checking if the
current working directory (the directory from which "inst_sge" is called)
matches the $SGE_ROOT directory.

In SGE 6.0/6.1 the shell function is in


The code where the check is done is protected by a if clause which only does
this check if the variable "strict" is set to true:

      # do not check for correct SGE_ROOT in case of -nostrict
      if [ "$strict" = true ]; then

As the comment indicates a command line parameter "-nostrict" would overwrite
this behavior. However the SGE 6.0/6.1 installation routine does not anymore
support the parameter "-nostrict" nor there is any evidence in the entire
installation routine
that the variable "strict" is set at all.

This is the root cause in my opinion why this problem occurred.

Change History (2)

comment:1 Changed 10 years ago by dlove

  • Resolution set to fixed

The mentioned bits aren't there.

comment:2 Changed 9 years ago by admin

  • Description modified (diff)
  • Severity set to minor
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.