array_sessions(5)array_sessions(5)NAMEarray_sessions - introduction to array sessions
DESCRIPTION
An array session is a group of processes all related to each other by a
single unique identifier, the array session handle. The processes don't
necessarily have to belong to the same parent-child chain, and don't even
have to be running on the same system. However, the default is for a
child process to inherit the array session handle of its parent, so in
the average case the processes in an array session are
parents/siblings/children of each other and reside on the same system.
An array session is considered to be active from the time it is first
created until the last process that is a member of it exits.
The goal of an array session is to correlate all the processes that
belong conceptually to the same login session or batch job, even if those
processes are running on several separate machines in an array. Then,
with the help of external software, the array session can potentially be
treated as a single unit for the purposes of accounting,
checkpoint/restart, job control, etc.
A process can create a new array session and place itself in it by using
the newarraysess(2) call. Ordinarily, this would only be done programs
like login or rshd, which are effectively logging a user into the system,
and programs like batch queue systems or cron, which are running jobs on
behalf of another user. A new array session is assigned an array session
handle that is unique to the current system only. If the process is
actually part of an existing array session on another system (e.g. the
process is part of a single job running across more than one node in an
array) it can change the handle of its array session to that of its
"parent" on the remote system using the setash(2) call. The parent's
array session handle would presumably be unique across the entire array,
although it would be the parent's responsibility to arrange for that.
The range of values that the kernel will assign as array session handles
is configurable so that it would be possible to design a server to
provide array-unique handles.
An array session is not the same thing as a POSIX session, though the two
concepts are similar on a single system. One important characteristic of
a POSIX session is that all of the processes included within it share a
single controlling terminal. That distinction does not exist for array
sessions: processes from two different array sessions might both be using
the same controlling terminal (e.g. by way of the newproj command) or
contrarily two processes in the same array session might have two
different controlling terminals (e.g. when running on different systems).
However, in the simple case of a local login with no remote interactions
an array session and a POSIX session would include the same set of
processes.
Page 1
array_sessions(5)array_sessions(5)SERVICE PROVIDER INFORMATION
Associated with every array session is a block of data known as the
service provider information. It is typically used to tag the array
session with certain identifying information for accounting or
statistical purposes. For example, a batch queuing system might store
information about the queue name and job initiator in this area. The
service provider information is reported as part of the array session
accounting data when the array session finally terminates.
The amount of storage available to an array session for holding service
provider information can vary from 0 to 1024 bytes, though the most
common lengths are 64 (the system default) or 128 bytes. If no specific
action has been taken to associate service provider information with an
array session, then the default system service provider information will
be associated with the array session instead.
The xactl(1m) program or the arsop(2) and arsctl(2) system calls can be
used to query or modify the contents or size of the system default
service provider information or the service provider information of a
particular array session. A user must generally be privileged to make
any modifications. Although the format of the service provider
information is not enforced by IRIX, there are two recommended formats
defined in /usr/include/sys/extacct.h: "format 1" (defined by the
structure acct_spi_t) is for systems that use 64 bytes of service
provider information, and "format 2" (defined by the structure
acct_spi_2_t) is for systems that use 128 bytes of service provider
information. Only format 1 service provider information is supported on
systems running IRIX 6.4 or earlier.
The system default service provider information is 64 bytes in length and
is always cleared to zeroes when the system is initially started. If
desired, the default size can be changed for boot-time array sessions by
modifying the spilen kernel variable using systune(1m).
SEE ALSOgetash(2), getspinfo(2), newarraysess(2), setash(2), setspinfo(2),
extacct(5), projects(5).
Page 2
