Custom Query (431 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (166 - 168 of 431)

Ticket Resolution Summary Owner Reporter
#1272 fixed IZ3288: load/save_sge_config.sh's "usage" output in one line only reuti
Description

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

        Issue #:      3288             Platform:     All      Reporter: reuti (reuti)
       Component:     gridengine          OS:        All
     Subcomponent:    clients          Version:      6.2u5       CC:    None defined
        Status:       NEW              Priority:     P3
      Resolution:                     Issue type:    DEFECT
                                   Target milestone: ---
      Assigned to:    roland (roland)
      QA Contact:     roland
          URL:
       * Summary:     load/save_sge_config.sh's "usage" output in one line only
   Status whiteboard:
      Attachments:

     Issue 3288 blocks:
   Votes for issue 3288:


   Opened: Sun Oct 24 05:56:00 -0700 2010 
------------------------


The scripts "load/save_sge_config.sh" use one `echo` command to display its usage. The default under Linux's `echo` is not to interpret the
escape sequences and will result in one long line only, although the intention was to have it printed out on several ones. This might be
different on other platforms though. Snippet to get the correct behavior would be to add a "-e" to allow that escape sequences will be
honored (works with the plain /bin/echo or bash's builtin):

INFOTEXT=echo
nonewline=`$INFOTEXT "\n"`
if [ "$nonewline" == "\n" ]; then
    INFOTEXT="echo -e"
fi
#1271 fixed IZ3287: References to REQNAME shoud be removed Dave Love <d.love@…> reuti
Description

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

        Issue #:      3287             Platform:     All      Reporter: reuti (reuti)
       Component:     gridengine          OS:        All
     Subcomponent:    man              Version:      6.2u5       CC:    None defined
        Status:       NEW              Priority:     P3
      Resolution:                     Issue type:    DEFECT
                                   Target milestone: ---
      Assigned to:    andreas (andreas)
      QA Contact:     andreas
          URL:
       * Summary:     References to REQNAME shoud be removed
   Status whiteboard:
      Attachments:

     Issue 3287 blocks:
   Votes for issue 3287:


   Opened: Sun Oct 24 05:01:00 -0700 2010 
------------------------


At several locations in the docs (man & html) are references to $REQNAME. I would assume that this was the original name of the variable
which is nowadays called $REQUEST. As $REQNAME is (no longer) listed in `man qsub` as an available variable, all references to it should be
removed and maybe then the old variable really be abandoned from being set.

$ grep -r REQNAME *
doc/man/man5/sge_pe.5:procedure is redirected to the file \fIREQNAME\fP.po\fIJID\fP in the
doc/man/man5/sge_pe.5:with \fIREQNAME\fP being the name of the job as
doc/man/man5/sge_pe.5:the standard error output is redirected to \fIREQNAME\fP.pe\fIJID\fP
doc/man/man5/sge_pe.5:procedure is also redirected to the file \fIREQNAME\fP.po\fIJID\fP in the
doc/man/man5/sge_pe.5:with \fIREQNAME\fP being the name of the job as
doc/man/man5/sge_pe.5:the standard error output is redirected to \fIREQNAME\fP.pe\fIJID\fP
doc/htmlman/htmlman5/sge_pe.html:     <I>REQNAME</I>.po<I>JID</I>  in the job's working directory (see <B><A
HREF="../htmlman1/qsub.html?pathrev=V62u5_TAG">qsub(1)</A></B>),
doc/htmlman/htmlman5/sge_pe.html:     with <I>REQNAME</I> being the name  of  the  job  as  displayed  by
doc/htmlman/htmlman5/sge_pe.html:     <I>REQNAME</I>.pe<I>JID</I>
doc/htmlman/htmlman5/sge_pe.html:     redirected  to  the  file <I>REQNAME</I>.po<I>JID</I> in the job's working
doc/htmlman/htmlman5/sge_pe.html:     directory (see <B><A HREF="../htmlman1/qsub.html?pathrev=V62u5_TAG">qsub(1)</A></B>), with
<I>REQNAME</I> being the name of  the
doc/htmlman/htmlman5/sge_pe.html:     redirected to <I>REQNAME</I>.pe<I>JID</I>
source/daemons/execd/exec_job.c:            var_list_set_string(&environmentList, "REQNAME", reqname);
source/daemons/execd/exec_job.c:      /* JG: TODO (ENV): do we need REQNAME and REQUEST? */
source/dist/ckpt/cpr_clean_command:F=~/$REQNAME.co$1
source/dist/ckpt/cpr_restart_command:F=~/$REQNAME.co$1
source/dist/ckpt/README.cpr:$REQNAME.co$JOD_ID.
source/dist/ckpt/cpr_ckpt_command:F=~/$REQNAME.co$1
source/dist/ckpt/cpr_migration_command:F=~/$REQNAME.co$1
#1267 invalid IZ3283: -builtin- job startup method inherits $TERM from the execd and wrong owner of tty file reuti
Description

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

        Issue #:      3283             Platform:     All      Reporter: reuti (reuti)
       Component:     gridengine          OS:        All
     Subcomponent:    clients          Version:      6.2u5       CC:    None defined
        Status:       NEW              Priority:     P3
      Resolution:                     Issue type:    DEFECT
                                   Target milestone: ---
      Assigned to:    roland (roland)
      QA Contact:     roland
          URL:
       * Summary:     -builtin- job startup method inherits $TERM from the execd and wrong owner of tty file
   Status whiteboard:
      Attachments:

     Issue 3283 blocks:
   Votes for issue 3283:


   Opened: Wed Sep 29 03:11:00 -0700 2010 
------------------------


Using the -builtin- job startup for an interactive login, the set $TERM inside this session is not the one from the connected terminal, but
inherited from the sgeexecd, and reflects the one which was used to start the sgeexed. This can lead to "dumb" on RedHat system, or "linux"
for openSUSE when the daemons are simply started on a node in a cluster without any monitor connected. Some of these don't allow `vi` or
`less` to work as expected (with "linux" it seems working though). It should instead reflect the type of terminal which the user is actually
using. The workaround is to hardcode a value in /etc/profile or similar file for it.


Furthermore the protection of the generated /dev/pts/1 or similar file shows that it's owned by root, but it should be owned by the starting
user:

http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=284334
Note: See TracQuery for help on using queries.