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: + 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. + Each new process inherits the job ID and limits from its parent process. + All point of entry processes (job initiators) create a new job and set the job limits appropriately. + Users can raise and lower their own job limits within maximum values specified by the system administrator. + The job initiator performs authentication and security checks. + 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 ALSO genlimits(1M), jlimit(1), jobs(1), jstat(1), showlimits(1). IRIX Admin: Resource Administration Page 2