[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.

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

        Issue #:      1047             Platform:     All           Reporter: crei (crei)
       Component:     gridengine          OS:        All
     Subcomponent:    clients          Version:      current          CC:    None defined
        Status:       NEW              Priority:     P3
      Resolution:                     Issue type:    ENHANCEMENT
                                   Target milestone: ---
      Assigned to:    andreas (andreas)
      QA Contact:     roland
          URL:
       * Summary:     qacct should dump scale unit for data output
   Status whiteboard:
      Attachments:

     Issue 1047 blocks:
   Votes for issue 1047:


   Opened: Thu May 13 06:12:00 -0700 2004 
------------------------


a qacct -j JOB_ID

should dump scale unit for number values:

e.g.:

maxvmem      15130624.000

should be printed as

maxvmem      14.430M

   ------- Additional comments from sgrell Mon Dec 12 02:49:29 -0700 2005 -------
Changed subcomponent.

Stephan

[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.)