Custom Query (431 matches)
Results (61 - 63 of 431)
Ticket | Resolution | Summary | Owner | Reporter |
---|---|---|---|---|
#272 | invalid | IZ1789: Ambiguity in "Administering Policies" doc | js631 | |
Description |
[Imported from gridengine issuezilla http://gridengine.sunsource.net/issues/show_bug.cgi?id=1789] Issue #: 1789 Platform: All Reporter: js631 (js631) Component: gridengine OS: All Subcomponent: doc Version: 6.0u6 CC: None defined Status: NEW Priority: P3 Resolution: Issue type: DEFECT Target milestone: --- Assigned to: andreas (andreas) QA Contact: skonta URL: http://gridengine.sunsource.net/servlets/ReadMsg?list=users&msgNo=12603 * Summary: Ambiguity in "Administering Policies" doc Status whiteboard: Attachments: Issue 1789 blocks: Votes for issue 1789: Opened: Mon Sep 12 08:32:00 -0700 2005 ------------------------ http://docs.sun.com/app/docs/doc/817-5677/6ml49n2bt?a=view#i999558 I just read through the "Sharing Functional Ticket Shares" section. In it it says: * Selecting the Share Functional Tickets check box means that functional shares are replicated among jobs. * Clearing the Share Functional Tickets check box means that functional shares are distributed among jobs. Then in the following paragraph, it seems to contradict the above: "Jobs with many siblings that belong to the same category member receive relatively small share portions if you select the Share Functional Tickets check box. On the other hand, if you clear the Share Functional Tickets check box, all sibling jobs receive the same share amount as their category member." Before I explain my confusion, the checkbox in the new qmon GUI is labeled "Share Functional Shares". Anyway, it would seem that "if you clear the Share Functional Tickets check box, all sibling jobs receive the same share amount as their category member" implies the first bullet point, which requires the checkbox be selected. ------- Additional comments from surajp Thu Mar 5 05:15:31 -0700 2009 ------- Reassigning issue to Sandra... |
|||
#20 | invalid | IZ178: New cluster configuration parameter "max_jobs" | ernst | |
Description |
[Imported from gridengine issuezilla http://gridengine.sunsource.net/issues/show_bug.cgi?id=178] Issue #: 178 Platform: All Reporter: ernst (ernst) Component: gridengine OS: All Subcomponent: doc Version: 6.0 CC: None defined Status: NEW Priority: P4 Resolution: Issue type: ENHANCEMENT Target milestone: --- Assigned to: andreas (andreas) QA Contact: skonta URL: * Summary: New cluster configuration parameter "max_jobs" Status whiteboard: Attachments: Issue 178 blocks: Votes for issue 178: Opened: Wed Mar 6 05:12:00 -0700 2002 ------------------------ A new cluster configuration parameter will be available in the next main release. It won't be available in 5.3. I changed the manpage. Documentation still has to be done. sge_conf(5): ... max_jobs The number of active (not finished) jobs simultaneously allowed in xxQS_NAMExx. is controlled by this parameter. A value greater than 0 defines the limit. The default value 0 means "unlimited". If the max_jobs limit is exceeded by a job submission then the submission command exits with exit status 25 and an appropriate error mes sage. Changing max_jobs will take immediate effect. This value is a global configuration parameter only. It cannot be overwritten by the execution host local configu ration. ... ------- Additional comments from andreas Thu Oct 21 08:37:20 -0700 2004 ------- Assign User/Admin/Install issues to Mark O'Brien. ------- Additional comments from surajp Mon Mar 23 01:30:59 -0700 2009 ------- Reassigning issue to Sandra. |
|||
#276 | fixed | IZ1803: Binary jobs are problematic for starter and epilog scripts | roland | |
Description |
[Imported from gridengine issuezilla http://gridengine.sunsource.net/issues/show_bug.cgi?id=1803] Issue #: 1803 Platform: All Reporter: roland (roland) Component: gridengine OS: All Subcomponent: execution Version: 6.0u3 CC: None defined Status: NEW Priority: P3 Resolution: Issue type: DEFECT Target milestone: --- Assigned to: pollinger (pollinger) QA Contact: pollinger URL: * Summary: Binary jobs are problematic for starter and epilog scripts Status whiteboard: Attachments: Issue 1803 blocks: Votes for issue 1803: Opened: Mon Sep 19 02:14:00 -0700 2005 ------------------------ I have a customer with a Sun Grid Engine 6.x installation to whom we provide a special starter method script to select some resources, set environment variables, and start the job. In general, this ksh starter method starts the job using $SGE_STARTER_SHELL_PATH "$@" This normally works, but will NOT WORK in general when a "binary" job was submitted using qsub -b y. In this binary case, $SGE_STARTER_SHELL_PATH="/bin/csh" and $1=="-c" and $2 is all user arguments in one string. Problem #1 is that that is not all the arguments the script gets. If the user typed qsub -b y /my/path/to/myprogram arg1 arg2 arg3 $2 will be "/my/path/to/myprogram arg1 arg2 arg3" but $3 will be "arg1" and $4=arg2 and $5=arg3. THIS IS A BUG! In fact, if arg1 were "-none" then /bin/csh parse the -c and the $2, but then *also* parses the -none in $3 and will NOT EXECUTE (because csh's -n option means do not execute) the user's program in $2! For example, try qsub -b y /bin/echo -n " arg2 " " arg3" "arg4 " Lesser problem #2 is only evident if there are spaces (or shell metacharacters) in the arguments. If the user typed qsub -b y /my/path/to/myprogram " arg1 " " arg2" "arg3 " then $2 is "/my/path/to/myprogram arg1 arg2 arg3 " but when /bin/csh reinterprets this string, the effect of the user quotation marks (the spaces that should be with the args) is lost, and the actual program will see arguments "arg1" "arg2" "arg3" (assuming that problem #1 is solved). dean.stanton@sun.com 2005-04-14 03:14:18 GMT Problem #3 is that the epilog appears to be invoked using the user's $SHELL with arguments -c "{path to epilog} {job's program-args}" and then an additional copy of the job's program-args. I issued qsub -b y /home/stanton/scripts/args " arg2 " " arg3" "arg4 " and my epilog was invoked with $0 is '/path/to/my/debug_epilog' $* is (arg2 arg3 arg4) There is no reason that the epilog should need the target program's arguments. If the epilog wants those arguments, it surely wants the name of the target program, as well; $* is a poor way to provide that optional info to the epilog. And these arguments have been reparsed, so the spacing has been lost. What's worse, the user's shell is invoked (as in #1) like /bin/csh -c "/path/to/my/debug_epilog arg2 arg3 arg4 " followed by a repeat of the individual arguments " arg2 " " arg3" "arg4 " These are not intended as arguments to /bin/csh nor to epilog but to the job's target program. In particular, if the first argument starts with -n, then as described in #1 above, the epilog is NOT ACTUALLY INVOKED by csh! Of course, the intention is that the epilog run for every job. This is a more serious bug, as users should not be able to keep the epilog from running. And when the user's shell is tcsh, it is even more fussy about its arguments. When csh sees an unknown argument, such as -w, it seems to ignore it: /bin/csh -c "echo -w arg2" -w arg2 -w arg2 But when tcsh sees an unknown argument, it complains: /bin/tcsh -c "echo -w arg2" -w arg2 Unknown option: `-w' Usage: tcsh [ -bcdefilmnqstvVxX ] [ argument ... ]. and exits with an error status (1). These notes were in the E-mail sent to the SGE administrative E-mail address: [26889:1783]: execvp(/bin/tcsh, "-tcsh" "-c" "/gridware/sge/debug_epilog -none -time " "-none" "-time") [53:1829]: wait3 returned 1873 (status: 256; WIFSIGNALED: 0, WIFEXITED: 1, WEXITSTATUS: 1) [53:1829]: epilog exited with exit status 1 [53:1829]: reaped "epilog" with pid 1873 [53:1829]: epilog exited not due to signal [53:1829]: epilog exited with status 1 Issue #4 is that if $SHELL is /bin/csh (and perhaps for tcsh, as well), the program should arguably be invoked with the -f (fast) flag, as well, that skips sourcing of the user's ~/.cshrc file. The reason this can matter is that if the user's ~/.cshrc file prints anything, that output is included in the job's output (after the target program is invoked, when the epilog invocation is attempted). tty and stty commands will often fail with a message like "not a tty". Again, using /usr/bin/env might be a better way to invoke the epilog than /bin/csh (or the user's $SHELL). ------- Additional comments from roland Tue Dec 6 08:34:01 -0700 2005 ------- *** Issue 1337 has been marked as a duplicate of this issue. *** |
Note: See TracQuery
for help on using queries.