SESSION_CONF(5) File Formats Manual SESSION_CONF(5) NAME session_conf - Univa Grid Engine session configuration DESCRIPTION When Univa Grid Engine client commands interact with Univa Grid Engine server components (see sge_qmaster(1)) then this is done by using an interface named GDI (Grid Engine Data Interface). This interface is used to send client requests to the Univa Grid Engine system that are then handled within the server component and answered by a response message that contains the result for the client request. This GDI interface is also used for internal Univa Grid Engine communi- cation between components running on execution hosts (see sge_execd(1)) as well as for internal communication between components within the sge_master(1) component itself. GDI requests can be divided into two categories: Requests that will change the configuration/state of the Univa Grid Engine system (read- write-requests) and requests that will gather information to display the configuration/state of the Univa Grid Engine system (read-only- requests). Univa Grid Engine 8.2 has been redesigned so that read-write-requests and read-only-requests can be executed completely independently from each other. Furthermore up to 64 read-only requests can work in paral- lel which is not possible in Sun Grid Engine, Oracle Grid Engine and other open source versions of Grid Engine. This ensures faster response times for all requests and has a huge positive impact on the cluster throughput. The drawback of this approach is that GDI-read-only requests might not see the outcome of recently executed read-write requests in certain situations. E.g. it might happen that a user submits a job (read- write-request) and immediately does a qstat -j (read-only- request) which responds with an error which says that the previously created job does not exist. In some cases such behavior may cause problems and it is desired that requests should be executed in sequence and for this reason GDI ses- sions have been introduced that guarantee a consistent view onto the Univa Grid Engine system. Internally read-only requests that are exe- cuted within the control of a session are delayed until they can see all changes that have happened previously within the same session. The maximum delay depends on the Univa Grid Engine system load and the num- ber of threads that are active. This value also can be influenced by the max_reader_delay parameter which can be defined as qmaster_param in the Univa Grid Engine global configuration (see sge_conf(5)) A GDI session is a new configuration object in Univa Grid Engine 8.2 which can be created, modified and deleted by managers or users that are members of the sessionusers access control list. FORMAT The sections below describe the format of the template file for session objects. Via the -asi, -Asi, -msi, -Msi options of the qconf(1) com- mand session can be added and modified. The -csi switch can be used to create a session with default parameters. Any of these change opera- tions can be rejected by the Univa Grid Engine system, as a result of a failed integrity verification. Qconf(1) -ssil will return a list of all existing sessions in an Univa Grid Engine system. Details of a session are shown with the command qconf(1) -ssi. Note, Univa Grid Engine allows backslashes (\) be used to escape new- line (\newline) characters. The backslash and the newline are replaced with a space ( ) character before any interpretation. The following list of parameters specifies the session configuration file content: session_id The session ID of a session. For sessions that should be created the value for this attribute has to be NONE so that the sge_qmaster(1) process can assign a new unique session ID. owner User name of the user that owns the session. If NONE is specified as username during the creation of a new session then the executing user of the configuration command will be the owner of that session. Only managers and the session owner are allowed to modify or to delete an existing session and if a session gets created by root or a manager account on behalf of a regular user then that user should be a member of the sessionusers access control list. duration Duration of a session in a format as defined for time in sge_types(1). The duration influences the lifetime of a session. Lifetime of a ses- sion begins when the session is created and it ends when the session is not used for the specified amount of time defined by the duration attribute. Lifetime of a session is automatically increased by adding duration to the end_time of that session when it is used. The default duration of a session is 900 seconds if this is not speci- fied otherwise in the qmaster_param named gdi_request_session_timeout (see sge_conf(5)) The sge_qmaster(1) process tries to find sessions where the lifetime ended every 15 minutes and it will delete those sessions automatically. Although unused sessions will be deleted automatically it is recom- mended to delete sessions manually using the qconf(1) -dsi command once a session is not needed anymore. start_time Time when the session was created. Start_time of a session cannot be specified. It is shown with qconf(1) -ssi. end_time Possible end time of a session. After creation the end_time of a ses- sion is set to start_time plus duration. End_time is moved forward when the session is used so that it still remains valid for the amount of time specified by duration after use. If the session was not used then it is tagged for deletion. The sge_qmaster(1) process tries to find unused sessions every 15 minutes and it will delete those sessions automatically. Although unused ses- sions will be deleted automatically it is recommended to delete ses- sions manually using the qconf(1) -dsi command when a session is not needed anymore. The end_time of a session is shown by the commands qconf(1) -ssi and -ssil. SEE ALSO sge_intro(1), sge__types(1), qconf(1), COPYRIGHT See sge_intro(1) for a full statement of rights and permissions. Univa Grid Engine File Formats UGE 8.5.4 SESSION_CONF(5)