[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

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

Status: Resolution: Priority:

Summary: [natural language search...] URL: [natural language search...] Status whiteboard: [natural language search...]

}}}

For postgres and oracle, indexing is missing on columns j_job_number, j_task_number, j_pe_task_id in the sge_job table. See, for instance, ​http://forums.oracle.com/forums/thread.jspa?threadID=2155087&tstart=0

I guess the postgres case is more important for the community than the oracle one.