Opened 16 years ago

Closed 9 years ago

#158 closed defect (fixed)

IZ949: When qconf fails during installation, the diagnostic is incorrect

Reported by: uddeborg Owned by:
Priority: normal Milestone:
Component: sge Version: 6.0beta
Severity: minor Keywords: install
Cc:

Description

[Imported from gridengine issuezilla http://gridengine.sunsource.net/issues/show_bug.cgi?id=949]

        Issue #:      949              Platform:     All       Reporter: uddeborg (uddeborg)
       Component:     gridengine          OS:        All
     Subcomponent:    install          Version:      6.0beta      CC:    None defined
        Status:       VERIFIED         Priority:     P3
      Resolution:     FIXED           Issue type:    DEFECT
                                   Target milestone: ---
      Assigned to:    andy (andy)
      QA Contact:     dom
          URL:
       * Summary:     When qconf fails during installation, the diagnostic is incorrect
   Status whiteboard:
      Attachments:

     Issue 949 blocks:
   Votes for issue 949:


   Opened: Fri Apr 2 07:27:00 -0700 2004 
------------------------


When I tried to install the beta on a host, the
procedure failed during the "Checking hostname
resolving" phase.  After failing, it prints "The
error message was:" and then the usage message
from qconf.

Trying to trace this a little, I came across this
code in CheckHostNameResolving() in inst_execd.sh

      $SGE_BIN/qconf -sh > /dev/null 2>&1
      if [ $? = 1 ]; then
         errmsg=`$SGE_BIN/qconf 2>&1`
      else
         errmsg=`$SGE_BIN/qconf -sh 2>&1 |  grep
denied:`
      fi

Here first qconf is run with the "-sh" flag.  Then
 when it fails, it is run again, in order to
capture the error message.  But if the exit code
was 1, it is run without the -sh flag, which seems
like the bug.  Ran in this way it does give the
usage message, but it is not the error message it
got (and discarded) in the first attempt.

   ------- Additional comments from andy Tue Apr 6 00:58:46 -0700 2004 -------
Fixed.

Call "qconf -sh" in case of error.

   ------- Additional comments from uddeborg Wed Apr 28 04:27:21 -0700 2004 -------
I've now verified the fix in beta 2.  (Am I, as a reporter, supposed
to do this step?  Should I be the one closing too/instead?)

Change History (1)

comment:1 Changed 9 years ago by dlove

  • Resolution set to fixed
  • Severity set to minor
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.