job_limits(5)job_limits(5)NAME
job_limits, jobs - overview of job limits
DESCRIPTION
Job limits software helps ensure that each user has access to the
appropriate amount of system resources such as CPU time and memory and
makes sure that users do not exceed their allotted amount. Job limits
software can improve system throughput and utilization by restricting how
much of a machine each user can use.
With the IRIX kernel job limits feature, all processes associated with a
particular login session or batch submission are encapsulated as a single
logical unit called a job. The job is the container used to group
processes by login session.
A job is a group of related processes all descended from a point of entry
process and identified by a unique job ID. A job can contain multiple
process groups, sessions, or array sessions and all processes in one of
these subgroups are always contained within one job.
Limits on resource usage are applied on a per user basis for a particular
job and these limits are enforced by the kernel. All processes are
associated with a particular job and are identified by the job ID. The
processes belonging to a particular job can be limited, controlled,
queried, and accounted for as a unit. This allows a system administrator
to set job-specific limits on CPU time, memory, file space, and other
system resources. The user limits database (ULDB) allows user-specific
limits for jobs. If no ULDB is defined, job limits are the same for all
jobs. Work on a machine is submitted in a variety of ways, such as an
interactive login, a submission from a workload management system, a cron
job, or a remote access such as rsh, rcp, or array services. Each of
these points of entry create an original shell process and multiple
processes flow from that original point of entry. The IRIX operating
system currently supports limits on how many system resources an
individual process can consume, but not on the aggregate of the processes
resulting from a point of entry process. The kernel job provides a means
to limit the resource usage of all the processes resulting from a point
of entry.
Not every process on the system is part of a job. That is, only
processes which are started by a login initiator like login, rlogin, rsh
and so on, get assigned a job ID.
IRIX job limits have the following characteristics:
o A job is an inescapable container. A process cannot leave the job
nor can a new process be created outside the job without explicit
action, that is, a system call with root privilege.
o Each new process inherits the job ID and limits from its parent
process.
Page 1
job_limits(5)job_limits(5)
o All point of entry processes (job initiators) create a new job and
set the job limits appropriately.
o Users can raise and lower their own job limits within maximum values
specified by the system administrator.
o The job initiator performs authentication and security checks.
o The process control initialization process (init(1M)) and startup
scripts called by init are not part of a job and have a job ID of
zero.
Job initiators can be categorized as either interactive or batch
processes. Limit domain names are defined by the system administrator
when the user limits database (ULDB) is created.
Note: The existing IRIX commands jobs(1), fg(1), and bg(1) man pages
apply to shell "jobs" and are not related to IRIX kernel job limits.
For information about the application programming interface (API) for job
limits and the ULDB, see IRIX Admin: Resource Administration.
FILES
/usr/etc Contains the job limits administrator
command, genlimits
/usr/bin Contains the job limits user commands,
jlimit,jstat, and showlimits
/etc/jlimits.in ULDB configuration file
/etc/jlimits.m Local ULDB mdbm file
/etc/jlimits The jlimits.in file is parsed into the
colon delimited jlimits file, which is
used to load job limits into the local
ULDB jlimits.m file or into the NIS
master map.
SEE ALSOgenlimits(1M), jlimit(1), jobs(1), jstat(1), showlimits(1).
IRIX Admin: Resource Administration
Page 2
