Custom Query (431 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (28 - 30 of 431)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Ticket Resolution Summary Owner Reporter
#171 fixed IZ1028: Allow SIGTRAP to enable debugging uddeborg
Description

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

        Issue #:      1028             Platform:     All        Reporter: uddeborg (uddeborg)
       Component:     gridengine          OS:        All
     Subcomponent:    execution        Version:      6.0beta2      CC:    None defined
        Status:       STARTED          Priority:     P3
      Resolution:                     Issue type:    PATCH
                                   Target milestone: ---
      Assigned to:    andreas (andreas)
      QA Contact:     pollinger
          URL:
       * Summary:     Allow SIGTRAP to enable debugging
   Status whiteboard:
      Attachments:
                      Date/filename:                    Description:                                          Submitted by:
                      Fri May 7 00:11:00 -0700 2004: ## Minimum patch to just allow SIGTRAP too. (text/plain) uddeborg

     Issue 1028 blocks:
   Votes for issue 1028:


   Opened: Fri May 7 00:10:00 -0700 2004 
------------------------


I am trying to debug some problems I have with the
beta 2, and in the process wanted to run sge_execd
and sge_shepherd under the debugger.  That didn't
work.  After a while I realised it is because the
application blocks the SIGTRAP signal.

In sig_handlers.c actually all signals but a
selected set is blocked.  I don't see why this is
a good idea, but maybe I miss something.  In any
case I think allowing SIGTRAP would make sense.

   ------- Additional comments from uddeborg Fri May 7 00:11:30 -0700 2004 -------
Created an attachment (id=14)
Minimum patch to just allow SIGTRAP too.

   ------- Additional comments from andreas Fri Jun 17 06:11:16 -0700 2005 -------
Chaned to execution.

   ------- Additional comments from roland Mon Jun 20 00:43:51 -0700 2005 -------
take it

   ------- Additional comments from roland Mon Jun 20 06:07:09 -0700 2005 -------
I've enabled SIGTRAP for the shepard in our maintrunk. We need to verify that
this doesn't lead to any negative effects.
#179 fixed IZ1061: Trace file does not get new data after chown over NFS uddeborg
Description

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

        Issue #:      1061             Platform:     All        Reporter: uddeborg (uddeborg)
       Component:     gridengine          OS:        All
     Subcomponent:    kernel           Version:      6.0beta2      CC:    None defined
        Status:       VERIFIED         Priority:     P3
      Resolution:     DUPLICATE       Issue type:    DEFECT
                                   Target milestone: ---
      Assigned to:    andreas (andreas)
      QA Contact:     andreas
          URL:
       * Summary:     Trace file does not get new data after chown over NFS
   Status whiteboard:
      Attachments:

     Issue 1061 blocks:
   Votes for issue 1061:


   Opened: Fri May 21 09:22:00 -0700 2004 
------------------------


In main in shepherd.c, the job's trace file is
first created, and a first line where shepherd
says it was called and the uid and euid is
written.  Then the file's owner is changed to the
user running the job.  After that several more
lines are written.  If the spool directory is
mounted over NFS, all these writes fail.

I assume the reason is, contrary to the comment in
shepherd_trace_chown_intern says, that the
state-less NFS doesn't care if you have a file
descriptor open.  Each write is instead checked
for permission.  And after having changed back to
the euid of the SGE administrator, one no longer
has permission to write to this file.  (If the
write system call actually tells you so seems to
be a bit dependent on OS version and NFS flags.)

   ------- Additional comments from pollinger Wed May 26 01:53:06 -0700 2004 -------
The reason is, in fact, that NFS doesn't provide a proper way to
append to a file from two processes (even on the same host)
concurrently. So whenever a file handle is closed, whatever has been
written to the file from the other process since the file handle was
opened is overwritten.

This is documented in some creat(2) man pages (e.g of Linux) and
applies to most NFS Server implementations - an exception seems to be
the Irix 6.5 NFS Server which seems to handle appending correctly.

In our case this means, the output of the parent shepherd overwrites
the outputs of all child shepherds (which are forked to execute
prolog, pe_start, job, pe_stop and epilog).

This bug has already been reported (and fixed) as issue 1021.


*** This issue has been marked as a duplicate of 1021 ***

   ------- Additional comments from pollinger Wed May 26 01:55:37 -0700 2004 -------
Edit: This is not a duplicate of Issue 1021, it's a duplicate of Issue
1012.

   ------- Additional comments from uddeborg Wed May 26 08:23:43 -0700 2004 -------
Yes, that seems to be the same thing.  And your fix does indeed seem
to solve my problems.  (Including some consequential problems I had.)
#224 fixed IZ1443: code cleanup in builtin_starter.c:start_command() Dave Love <d.love@…> uddeborg
Description

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

        Issue #:      1443             Platform:     All     Reporter: uddeborg (uddeborg)
       Component:     gridengine          OS:        All
     Subcomponent:    execution        Version:      6.0u3      CC:    None defined
        Status:       NEW              Priority:     P3
      Resolution:                     Issue type:    TASK
                                   Target milestone: ---
      Assigned to:    andreas (andreas)
      QA Contact:     pollinger
          URL:
       * Summary:     code cleanup in builtin_starter.c:start_command()
   Status whiteboard:
      Attachments:
                      Date/filename:                     Description:                                                              Submitted by:
                      Fri Jan 28 07:36:00 -0700 2005: #  Patch to remove the pre_args_ptr completely. (text/plain)                 uddeborg
                      Fri Jan 28 07:38:00 -0700 2005: #2 Patch to use *pre_args_ptr++ as the technique to assign args (text/plain) uddeborg

     Issue 1443 blocks:
   Votes for issue 1443:


   Opened: Fri Jan 28 07:35:00 -0700 2005 
------------------------


While investigating a problem with submitting
commands (issue 1442) I was confused bu tye use of
a pointer pre_args_ptr in the function
start_command in
source/daemons/shepherd/builtin_starter.c.  It is
set to point to the first element of pre_args, but
is then used as an array.  This original array
pre_args could be used instead.  I get the
impression that somebody intended to assign
successive values with the "*ptr++" idiom, but
then changed his mind and used ordinary array
indexing instead, without removing the pointer
variable from the code.

It was a bit confusing when reading the code, so I
would suggest cleaning it up.  It could be changed
in one of two ways.  Either the pre_args_ptr could
be removed, and all indexing could be done from
the original array.  Or the *ptr++ technique could
be used.  I'll attach two possible patches, one
for each case.

   ------- Additional comments from uddeborg Fri Jan 28 07:36:44 -0700 2005 -------
Created an attachment (id=36)
Patch to remove the pre_args_ptr completely.

   ------- Additional comments from uddeborg Fri Jan 28 07:38:31 -0700 2005 -------
Created an attachment (id=37)
Patch to use *pre_args_ptr++ as the technique to assign args

   ------- Additional comments from uddeborg Fri Jan 28 07:40:33 -0700 2005 -------
Oh, please note that these patches also include the bug fix I suggest
in issue 1442.  Sorry for mixing the two things together.

   ------- Additional comments from sgrell Tue Dec 6 08:17:23 -0700 2005 -------
Changed the Subcomponent.

Stephan

   ------- Additional comments from pollinger Tue Mar 7 02:24:51 -0700 2006 -------
Changed "Issue type" to task
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Note: See TracQuery for help on using queries.