Custom Query (431 matches)
Results (49 - 51 of 431)
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. |
|||
#174 | fixed | IZ1047: qacct should dump scale unit for data output | Dave Love <d.love@…> | crei |
Description |
[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 |
|||
#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.) |
Note: See TracQuery
for help on using queries.