*nix Documentation Project
·  Home
 +   man pages
·  Linux HOWTOs
·  FreeBSD Tips
·  *niX Forums

  man pages->IRIX man pages -> array_sessions (5)              


array_sessions(5)					     array_sessions(5)

NAME    [Toc]    [Back]

     array_sessions - introduction to array sessions

DESCRIPTION    [Toc]    [Back]

     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

									Page 1

array_sessions(5)					     array_sessions(5)

     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 ALSO    [Toc]    [Back]

     getash(2),	getspinfo(2), newarraysess(2), setash(2), setspinfo(2),
     extacct(5), projects(5).

									PPPPaaaaggggeeee 2222
[ Back ]
 Similar pages
Name OS Title
arsctl IRIX modify the behavior of array sessions
SSL_CTX_flush_sessions NetBSD remove expired sessions
SSL_flush_sessions Tru64 Remove expired sessions
SSL_CTX_flush_sessions Tru64 Remove expired sessions
SSL_flush_sessions OpenBSD remove expired sessions
SSL_CTX_flush_sessions OpenBSD remove expired sessions
issue.net Linux identification file for telnet sessions
rsvpfilter IRIX select which sessions of RSVP debugging output are displayed
unpack IRIX Unpacks an array of rank one into an array under control of a mask
nstrtel HP-UX specifies the number of telnet device files the kernel can support for incoming telnet sessions
Copyright © 2004-2005 DeniX Solutions SRL
newsletter delivery service