Custom Query (431 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (46 - 48 of 431)

Ticket Resolution Summary Owner Reporter
#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.
#162 fixed IZ963: Can't run HPUX binaries jeffbeadles
Description

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

        Issue #:      963              Platform:     HP        Reporter: jeffbeadles (jeffbeadles)
       Component:     gridengine          OS:        HP-UX
     Subcomponent:    install          Version:      6.0beta      CC:    None defined
        Status:       VERIFIED         Priority:     P1
      Resolution:     FIXED           Issue type:    DEFECT
                                   Target milestone: ---
      Assigned to:    andy (andy)
      QA Contact:     dom
          URL:
       * Summary:     Can't run HPUX binaries
   Status whiteboard:
      Attachments:

     Issue 963 blocks:
   Votes for issue 963:


   Opened: Thu Apr 8 09:39:00 -0700 2004 
------------------------


I mailed this to the dev list, but wanted to
make sure it's tracked and will be fixed in the
next release.

When trying to run install_execd;

"
./inst_sge[131]: 13757 Abort
/usr/lib/dld.sl: Can't open shared
library: /vol2/tools/SW/openssl-
0.9.7c/hp11/lib/libcrypto.sl.0.9.7
/usr/lib/dld.sl: No such file or directory
./inst_sge[57]: 13776 Abort(coredump)

Command failed: ./bin/hp11/qconf -sh

Probably a permission problem. Please check file
access permissions.
Check read/write permission. Check if SGE
daemons are running.
"

With a message like that, I know that it's not a
permission problem, but rather a missing shared
library.  So;

$ chatr bin/hp11/qconf
bin/hp11/qconf:
         shared executable
         shared library dynamic path search:
             SHLIB_PATH     disabled  second
             embedded path  disabled  first  Not
Defined
         shared library list:
             dynamic   /vol2/tools/SW/openssl-
0.9.7c/hp11/lib/libcrypto.sl.0.9.7
             dynamic   /usr/lib/libnsl.1
             dynamic   /usr/lib/libm.2
             dynamic   /usr/lib/libpthread.1
             dynamic   /usr/lib/libc.2
         shared library binding:
             deferred
         global hash table disabled
         plabel caching disabled
         global hash array size:1103
         global hash array nbuckets:3
         shared vtable support disabled
         static branch prediction disabled
         executable from stack: D (default)
         kernel assisted branch prediction
enabled
         lazy swap allocation disabled
         text segment locking disabled
         data segment locking disabled
         third quadrant private data space
disabled
         fourth quadrant private data space
disabled
         third quadrant global data space
disabled
         data page size: D (default)
         instruction page size: D (default)
         nulptr references disabled
         shared library private mapping disabled
         shared library text merging disabled

The problem is the line that reads;
"             SHLIB_PATH     disabled  second"

This says to not look in SHLIB_PATH for the
shared libraries.

To fix this, change the HP makefile/build rules
and add a "+s" to the link arguments for all of
the executables that need things from
$SHLIB_PATH.

It can also be modified post-build by running $
chatr +s enable bin/hp11/*

(I've verified that this works, at least on HPUX
11.11)

Regards,
        -Jeff

   ------- Additional comments from andy Mon Apr 19 05:01:01 -0700 2004 -------
Fixed in Beta2. Need feedback from user if it works

   ------- Additional comments from andy Mon Apr 19 05:02:17 -0700 2004 -------
.

   ------- Additional comments from jeffbeadles Tue Jul 13 07:31:50 -0700 2004 -------
Works great in the 6.0 "production" release.  Thanks Andy!
#166 duplicate IZ1010: Job array lack means to get email notification for the total array andreas
Description

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

        Issue #:      1010             Platform:     All           Reporter: andreas (andreas)
       Component:     gridengine          OS:        All
     Subcomponent:    qmaster          Version:      6.0beta2         CC:    None defined
        Status:       NEW              Priority:     P3
      Resolution:                     Issue type:    ENHANCEMENT
                                   Target milestone: ---
      Assigned to:    andreas (andreas)
      QA Contact:     ernst
          URL:
       * Summary:     Job array lack means to get email notification for the total array
   Status whiteboard:
      Attachments:

     Issue 1010 blocks:
   Votes for issue 1010:


   Opened: Fri Apr 30 05:15:00 -0700 2004 
------------------------


DESCRIPTION:
There is a need for a means to sumit job arrays
in a way allowing email notifications be requested
for the total job.

Workaround:
The following solution helps only in the last
phase of the e-mail
delivery: from the e-mail daemon to the inbox. It
doesn't reduce the
number of e-mails generated by SGE nor the number
of messages that
have to pass through any intermediate e-mail daemons.

So, the solution is to use procmail for e-mail
filtering. procmail is
set to run from .forward and is handed the message
from the
daemon instead of writting it into the inbox.
Procmail has duplicate
mails detection capabilities, explained in 'man
procmailex'. You can
set it to check for the jobid and deliver only one
message per jobid.
procmail keeps a small cache of already seen
matching sequences and so
if the tasks take too long to complete while many
other jobs finish,
it might allow more than one message per jobid;
however the cache size
is configurable, so you can play with it to obtain
the best results.

   ------- Additional comments from sgrell Mon Dec 12 02:55:45 -0700 2005 -------
Changed the Subcomponent.

Stephan
Note: See TracQuery for help on using queries.