Custom Query (431 matches)
Results (142 - 144 of 431)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #504 | fixed | IZ2544: qmake should be upgraded to Make 3.80 | elrond1999 | |
| Description |
[Imported from gridengine issuezilla http://gridengine.sunsource.net/issues/show_bug.cgi?id=2544]
Issue #: 2544 Platform: All Reporter: elrond1999 (elrond1999)
Component: gridengine OS: All
Subcomponent: clients Version: 6.1u3 CC: None defined
Status: NEW Priority: P3
Resolution: Issue type: ENHANCEMENT
Target milestone: ---
Assigned to: roland (roland)
QA Contact: roland
URL:
* Summary: qmake should be upgraded to Make 3.80
Status whiteboard:
Attachments:
Issue 2544 blocks:
Votes for issue 2544:
Opened: Mon Apr 7 01:06:00 -0700 2008
------------------------
I'm missing the $eval feature in the current qmake version (3.78). It's probably
not to hard to upgrade qmake to 3.8 or later. If this is not possible is it
possible to patch make myself? Do you have a ready patch that I can use somewhere?
------- Additional comments from andreas Mon Apr 7 01:38:38 -0700 2008 -------
I'm sorry, but we do not yet have such a patch.
Upgrading qmake to 3.80 or later is certainly possible, but to my knowledge
nobody is working on this right now. If you consider to pursue that I would
suggest to start by obtaining the source diff between 3.78 and 3.80 from the
make source tree. Based on that it might be possible to apply the change as a
patch (using patch(1) command) into SGE source tree.
------- Additional comments from rayson Mon Apr 7 21:05:19 -0700 2008 -------
I built qmake with gmake 3.8 a year ago. See:
http://gridengine.sunsource.net/servlets/ReadMsg?list=dev&msgNo=3016
Rayson
------- Additional comments from elrond1999 Tue Apr 8 01:10:51 -0700 2008 -------
Hi I tried to do what you said, but I was unable to put any SGE features into
make. It compiles and links with remote-sge.c but the resulting executable does
not understand sge options.. I probably did something wrong along the way :)
Maybe instead I need the 3.78 -> 3.81 make patch. Or the 3.78 ->
3.78-distributed patch.
------- Additional comments from rayson Tue Apr 8 05:56:38 -0700 2008 -------
Thanks for trying my changes.
I diff'ed 3.78 qmake vs 3.78 gmake, and I found that I missed one additional
additional in main.c. Without it SGE options are no handled by the new qmake.
int main (int argc, char ** argv)
#endif
{
...
...
PATH_VAR (current_directory);
+ /* read and strip options for remote execution */
+ remote_options(&argc, &argv);
#ifdef WINDOWS32
...
...
Thanks,
Rayson
------- Additional comments from rayson Tue Apr 8 06:03:15 -0700 2008 -------
Typo (yup, just woke up a few minutes ago), should be:
"I diff'ed 3.78 qmake vs 3.78 gmake, and found that I missed a change in main.c.
Without it SGE options are not handled by the new qmake."
Also, you will need to add the function declaration:
extern void remote_options PARAMS ((int *p_argc, char **p_argv[]));
BTW, if unsure, you can always download 3.78.1 from GNU, and diff main.c against
the SGE version.
Rayson
------- Additional comments from elrond1999 Thu Apr 10 01:08:27 -0700 2008 -------
That did it I now have what seems like a working 3.81 qmake. I had to hack the
Makefile to make it include remote-sge.c/o, so I'm not sure I've done the
./configure correctly but at least it works now.
|
|||
| #38 | fixed | IZ254: create and use function to get paths/files in active_jobs directory | joga | |
| Description |
[Imported from gridengine issuezilla http://gridengine.sunsource.net/issues/show_bug.cgi?id=254]
Issue #: 254 Platform: All Reporter: joga (joga)
Component: gridengine OS: All
Subcomponent: cleanup Version: 5.3 CC: None defined
Status: STARTED Priority: P3
Resolution: Issue type: ENHANCEMENT
Target milestone: not determined
Assigned to: ernst (ernst)
QA Contact: ernst
URL:
* Summary: create and use function to get paths/files in active_jobs directory
Status whiteboard:
Attachments:
Issue 254 blocks:
Votes for issue 254:
Opened: Wed May 15 01:16:00 -0700 2002
------------------------
execd has lots of code creating directory and file
paths in the jobs active directory depending on
job_id, ja_task_id, pe_task_id, an optional
filename, relative and absolute paths.
Make a function to create these paths and use it.
------- Additional comments from joga Wed May 15 01:17:12 -0700 2002 -------
started.
------- Additional comments from joga Tue May 21 07:08:48 -0700 2002 -------
daemons/execd/get_path.* has a new function
sge_get_active_job_file_path that delivers the required paths.
Some code has been changed to use this function, other code still has to be identified and changed.
The function could be more generalized to deliver other paths as well or use a function in utilib doing a similar job.
------- Additional comments from joga Wed May 22 06:16:42 -0700 2002 -------
Changed all code referencing the active_jobs directory in execd.
Some other code (source/common) still has to be changed.
|
|||
| #507 | fixed | IZ2552: dump if SGE daemons crash when admin_user != "root" | andreas | |
| Description |
[Imported from gridengine issuezilla http://gridengine.sunsource.net/issues/show_bug.cgi?id=2552]
Issue #: 2552 Platform: All Reporter: andreas (andreas)
Component: gridengine OS: All
Subcomponent: kernel Version: 6.1AR_snapshot3_6 CC: None defined
Status: REOPENED Priority: P2
Resolution: Issue type: DEFECT
Target milestone: ---
Assigned to: andreas (andreas)
QA Contact: andreas
URL:
* Summary: No core dump if SGE daemons crash when admin_user != "root"
Status whiteboard:
Attachments:
Date/filename: Description: Submitted by:
Fri Apr 11 08:10:00 -0700 2008: libcore.so.gz libcore.so for AMD64 Linux (application/x-gzip) andreas
Fri Apr 11 08:12:00 -0700 2008: libcore.c Source code for libcore.so (text/plain) andreas
Mon Apr 28 04:00:00 -0700 2008: libcore.so.gz libcore.so for lx24-ia64 (application/x-gzip) andreas
Mon Apr 28 04:01:00 -0700 2008: libcore.so.gz libcore.so for lx24-x86 (text/plain) andreas
Mon Apr 28 06:49:00 -0700 2008: 2552.diff Proposed patch (maintrunk) (text/plain) andreas
Tue May 13 02:23:00 -0700 2008: build.sh Build.sh that I used to build libcore.so from libcore.c attached earlier (text/plain) andreas
Issue 2552 blocks:
Votes for issue 2552:
Opened: Thu Apr 10 02:51:00 -0700 2008
------------------------
DESCRIPTION:
When SGE daemons crash no core file gets written if admin_user != "root" due to
security concerns.
WORKAROUND/FIX:
Under Solaris coreadm(1) can be used to give the kernel a waiver (per
process/globally) so that core files get written in this case.
Under Linux there are two means:
(1) For overriding it for all processes there is a
# sysctl -w kernel.core_setuid_ok=1
it is mentioned in
http://kbase.redhat.com/faq/FAQ_49_3652.shtm
for RHEL3 so I would assume it works in RHEL4 as well
(2) For overriding it indivudually there is a call
prctl(PR_SET_DUMPABLE,1,42,42,42);
due to
https://bugzilla.redhat.com/show_bug.cgi?id=104310
mentioning it as a bug when it is broke I would assume one can rely on it
------- Additional comments from andreas Thu Apr 10 05:00:34 -0700 2008 -------
Use of
prctl(PR_SET_DUMPABLE,1,42,42,42)
under Linux seems problematic as it were necessary to issue this prctl() anew
each time uid/euid changes:
http://linux-documentation.com/en/man/man2/prctl.html
------- Additional comments from andreas Thu Apr 10 05:38:01 -0700 2008 -------
Best approach to address this issue is to have the documentation explain how to
still get the core file.
Plan is to add a trouble shooting section to 6.2 Install Guide that refers
coreadm(1M) and sysctl -w kernel.core_setuid_ok
------- Additional comments from andreas Fri Apr 11 08:07:50 -0700 2008 -------
As it turned out that e.g. RHEL4 does not know
# sysctl -w kernel.core_setuid_ok=1
anymore the only resort to get a core dump under Linux appears to issue
prctl(PR_SET_DUMPABLE,1,42,42,42);
after each call to setuid(), seteuid(), setgid(), and setegid().
As workaround the use of libcore.so using LD_PRELOAD turned out to solve the
issue. E.g. to apply it for sge_execd one must change in
$SGE_ROOT/$SGE_CELL/common/sgeexecd
the line
$bin_dir/sge_execd
where sge_execd is started into
env LD_PRELOAD=/path/to/libcore.so $bin_dir/sge_execd
after execd restart a nice core.<pid> file is written in the spool directory
$SGE_ROOT/$SGE_CELL/spool/<host>/ of this execd when it gets killed using
# kill -SEGV <pid>
LD_PRELOAD though gets inherited to shepherds processes that are forked by such
an execd, but the jobs themselfs will not have it in their environments, except
if one was adding INHERIT_ENV=LD_PRELOAD to the execd_params section of the
cluster configuration sge_conf(5).
------- Additional comments from andreas Fri Apr 11 08:10:12 -0700 2008 -------
Created an attachment (id=164)
libcore.so for AMD64 Linux
------- Additional comments from andreas Fri Apr 11 08:12:04 -0700 2008 -------
Created an attachment (id=165)
Source code for libcore.so
------- Additional comments from andreas Mon Apr 28 04:00:50 -0700 2008 -------
Created an attachment (id=166)
libcore.so for lx24-ia64
------- Additional comments from andreas Mon Apr 28 04:01:50 -0700 2008 -------
Created an attachment (id=167)
libcore.so for lx24-x86
------- Additional comments from andreas Mon Apr 28 06:49:52 -0700 2008 -------
Created an attachment (id=168)
Proposed patch (maintrunk)
------- Additional comments from andreas Wed Apr 30 06:47:05 -0700 2008 -------
Fixed in Maintrunk for Linux sge_execds.
------- Additional comments from andreas Tue May 13 02:23:05 -0700 2008 -------
Created an attachment (id=171)
Build.sh that I used to build libcore.so from libcore.c attached earlier
|
|||
Note: See TracQuery
for help on using queries.
