Custom Query (431 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (37 - 39 of 431)

3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
Ticket Resolution Summary Owner Reporter
#149 invalid IZ889: Reference to Figure 8-9 is incorrect dbmarshall
Description

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

        Issue #:      889              Platform:     All      Reporter: dbmarshall (dbmarshall)
       Component:     gridengine          OS:        All
     Subcomponent:    doc              Version:      6.0         CC:    None defined
        Status:       NEW              Priority:     P5
      Resolution:                     Issue type:    DEFECT
                                   Target milestone: ---
      Assigned to:    andreas (andreas)
      QA Contact:     skonta
          URL:
       * Summary:     Reference to Figure 8-9 is incorrect
   Status whiteboard:
      Attachments:

     Issue 889 blocks:
   Votes for issue 889:


   Opened: Thu Mar 18 15:22:00 -0700 2004 
------------------------


I have discovered that Users Manual reference to
Figure 8-9, located in the "Example 2: Space
Sharing for Virtual Memory" section, manual page
209 is wrong.

The reference reads "a corresponding execution
host configuration for a host with 1 Gigabyte of
main memory is depicted in Figure 8-9."  In fact,
Figure 8-9 shows defining a per-host value for
h_vmem, but (in the context of "Example 2") should
show defining a per-host value for vitual_free.
Earlier references in the same chapter to Figure
8-9 are correct,  since in those other references,
h_vmem would need to be defined.

   ------- Additional comments from andreas Thu Oct 21 08:37:18 -0700 2004 -------
Assign User/Admin/Install issues to Mark O'Brien.

   ------- Additional comments from surajp Mon Mar 2 03:16:23 -0700 2009 -------
Reassigning issue to Sandra...

   ------- Additional comments from surajp Mon Mar 2 03:21:14 -0700 2009 -------
*** Issue 904 has been marked as a duplicate of this issue. ***
#158 fixed IZ949: When qconf fails during installation, the diagnostic is incorrect uddeborg
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?)
#160 fixed IZ960: Buffer sent to getgrgid_r is too small uddeborg
Description

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

        Issue #:      960              Platform:     Sun       Reporter: uddeborg (uddeborg)
       Component:     gridengine          OS:        Solaris
     Subcomponent:    kernel           Version:      6.0beta      CC:    None defined
        Status:       VERIFIED         Priority:     P3
      Resolution:     FIXED           Issue type:    DEFECT
                                   Target milestone: ---
      Assigned to:    adoerr (adoerr)
      QA Contact:     andreas
          URL:
       * Summary:     Buffer sent to getgrgid_r is too small
   Status whiteboard:
      Attachments:

     Issue 960 blocks:
   Votes for issue 960:


   Opened: Wed Apr 7 05:18:00 -0700 2004 
------------------------


My attempt to install on Solaris failed.  "qconf
-sh" returned the error message:

error: getgrgid(13) failed: No such file or directory

I tried to track this down.  It appears to be
because the buffer sent to getgrgid_r is too
small.  In the function sge_gid2group() in
source/libs/uti/sge_uidgid.c there is a call of
getgrgid_r with a buffer with a size of 2048.
This call fails when I run it on our 64 bit
Solaris machines.

According to the Solaris manual for getgrgid_r,
the maximum size which could be needed can be
found with the call sysconf(_SC_GETGR_R_SIZE_MAX).
 I tried this on a couple of platforms I have
available here, and got those figures:

Sparc, Solaris 8, 32 bit app: 7296
Sparc, Solaris 8, 64 bit app: 10496
PowerPC, AIX 5.2, 32 and 64 bit app: 20023
PARisc, HP-UX 11, 32 and 64 bit app: 2048
AMD64, Red Hat EL 3, 32 and 64 bit app: 1024
IA32, Red Hat EL 3, 32 bit app: 1024

It varies quite a lot, and 2048 obviously is too
small in several cases.  We have some groups with
rather many members, a bit over 100, which
probably affects this.  But not so many members
that an application should break.

Preferably, I'd suggest allocating a buffer with a
size taken from the return value of sysconf().
Otherwise, I would suggest to at least increase
the static size by an order of magnitude.

   ------- Additional comments from andreas Tue May 4 03:17:28 -0700 2004 -------
There is more than one function where this needs to be changed.

   ------- Additional comments from adoerr Tue May 11 05:57:48 -0700 2004 -------
Reassign

   ------- Additional comments from adoerr Sat May 22 07:33:41 -0700 2004 -------
Fixed.

   ------- Additional comments from uddeborg Thu May 27 02:38:42 -0700 2004 -------
I've rebuilt locally with source/libs/uti/sge_uidgid.c taken from
HEAD, and it seems to work fine now.
3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
Note: See TracQuery for help on using queries.