Custom Query (431 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (43 - 45 of 431)

Ticket Resolution Summary Owner Reporter
#35 fixed IZ245: qhost -l h=<hostname> does not work andreas
Description

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

        Issue #:      245              Platform:     All          Reporter: andreas (andreas)
       Component:     gridengine          OS:        All
     Subcomponent:    clients          Version:      V53_alpha1      CC:
                                                                            [_] uddeborg
                                                                            [_] Remove selected CCs
        Status:       REOPENED         Priority:     P4
      Resolution:                     Issue type:    DEFECT
                                   Target milestone: 6.0
      Assigned to:    andreas (andreas)
      QA Contact:     roland
          URL:
       * Summary:     qhost -l h=<hostname> does not work
   Status whiteboard:
      Attachments:
                      Date/filename:                             Description:                  Submitted by:
                      Wed Jan 30 06:40:00 -0700 2008: patch.diff That''s the diff (text/plain) andreas

     Issue 245 blocks:
   Votes for issue 245:


   Opened: Tue May 7 07:21:00 -0700 2002 
------------------------


DESCRIPTION:
Though one would expect it to work the 'hostname'
attribute can't be used
with qhost for selecting particular hosts.

WORK AROUND:
# qhost | grep <hostname>

SUGGESTED FIX:
The 'hostname' attribute is not in the 'host'
complex but in the 'queue' complex. For this
reason an exechost does not have a 'hostname'
attribute.To fix this problem the 'hostname'
attribute must be moved into the 'host' complex
and the host information must be filled into this
complex attribute from the exechost.

   ------- Additional comments from uddeborg Fri Jun 17 01:55:57 -0700 2005 -------
This problem still remains in 6.0u5 beta

   ------- Additional comments from sgrell Tue Dec 6 08:37:08 -0700 2005 -------
Changed subcomponent.

Stephan

   ------- Additional comments from roland Tue Nov 14 08:29:51 -0700 2006 -------
WORKAROUND:
qhost -h hostlist

   ------- Additional comments from dom Tue Jan 29 11:57:54 -0700 2008 -------
fixed in maintrunk and V61_BRANCH

   ------- Additional comments from andreas Wed Jan 30 06:39:15 -0700 2008 -------
Fix

http://gridengine.sunsource.net/servlets/ReadMsg?list=cvs&msgNo=9557

appears problematic. The attached patch could solve the actual problem.

   ------- Additional comments from andreas Wed Jan 30 06:40:44 -0700 2008 -------
Created an attachment (id=147)
That''s the diff
#55 invalid IZ304: sge_conf(5) binary_path not used for qrsh_starter andreas
Description

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

        Issue #:      304              Platform:     All           Reporter: andreas (andreas)
       Component:     gridengine          OS:        All
     Subcomponent:    qmaster          Version:      5.3beta1         CC:    None defined
        Status:       NEW              Priority:     P3
      Resolution:                     Issue type:    ENHANCEMENT
                                   Target milestone: ---
      Assigned to:    ernst (ernst)
      QA Contact:     ernst
          URL:
       * Summary:     sge_conf(5) binary_path not used for qrsh_starter
   Status whiteboard:
      Attachments:

     Issue 304 blocks:
   Votes for issue 304:


   Opened: Fri Jun 28 08:21:00 -0700 2002 
------------------------


DESCRIPTION:
The binary_path setting in local sge_conf(5) is
not considered when qrsh_starter
is started using rsh by qrsh. The man page says
binary_path is used in such a case.

sge_conf(5) binary_path is used for cluster tuning
purposes, as it can
be used to lower the load a NFS server is faced
with.

   ------- Additional comments from andreas Mon Jan 20 04:24:43 -0700 2003 -------
sge_conf(5) binary path does not apply to util bin binaries

   ------- Additional comments from andreas Fri Sep 10 02:28:08 -0700 2004 -------
WORKAROUND:
A symbolic link needs to be created to effectuate executable
pathes other than

    $SGE_ROOT/utilbin/<arch>/qrsh_starter

actually be used.


   ------- Additional comments from pollinger Fri Dec 9 08:32:28 -0700 2005 -------
Changed Subcomponent
#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.