Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
priocntl(1)			 User Commands			   priocntl(1)

NAME
       priocntl	  -   display	or  set	 scheduling  parameters	 of  specified
       process(es)

SYNOPSIS
       priocntl	-l

       priocntl	-d [-i idtype] [idlist]

       priocntl	-s [-c class] [	class-specific	options] [-i idtype] [idlist]

       priocntl	-e [-c class] [	class-specific	options] command [argument(s)]

DESCRIPTION
       The priocntl command displays or	 sets  scheduling  parameters  of  the
       specified  process(es). It can also be used to display the current con-
       figuration information for the system's process scheduler or execute  a
       command with specified scheduling parameters.

       Processes  fall into distinct classes with a separate scheduling	policy
       applied to each class. The process classes currently supported are  the
       real-time  class,  time-sharing	class,	interactive  class, fair-share
       class, and the fixed  priority  class.  The  characteristics  of	 these
       classes	and the	class-specific options they accept are described below
       in the USAGE section under the headings Real-Time  Class,  Time-Sharing
       Class,  Inter-Active Class, Fair-Share Class, and Fixed-Priority	Class.
       With appropriate	permissions, the priocntl command can change the class
       and other scheduling parameters associated with a running process.

       In  the default configuration, a	runnable real-time process runs	before
       any other process. Therefore, inappropriate use of real-time  processes
       can have	a dramatic negative impact on system performance.

       If  an  idlist  is present, it must appear last on the command line and
       the elements of the list	must be	separated by white space. If no	idlist
       is  present, an idtype argument of pid, ppid, pgid, sid,	taskid,	class,
       uid, gid, or projid  specifies  the  process  ID,  parent  process  ID,
       process	group  ID,  session  ID, task ID, class, user ID, group	ID, or
       project ID, respectively, of the	priocntl command itself.

       The command

       priocntl	-d [-i idtype] [idlist]

       displays	the class and  class-specific  scheduling  parameters  of  the
       process(es) specified by	idtype and idlist.

       The command

       priocntl	-s [-c class] [class-specific options] \
	    [-i	idtype]	[idlist]

       sets the	class and class-specific parameters of the specified processes
       to the values given on the command line.	The -c class option  specifies
       the  class  to be set. (The valid class arguments are RT	for real-time,
       TS for time-sharing, IA for inter-active, FSS for fair-share, or	FX for
       fixed-priority.)

       The class-specific parameters to	be set are specified by	the class-spe-
       cific options as	explained under	the appropriate	heading	below. If  the
       -c  class  option  is  omitted, idtype and idlist must specify a	set of
       processes which are all in the same class, otherwise an error  results.
       If  no  class-specific  options are specified, the process's class-spe-
       cific parameters	are set	to the default values for the class  specified
       by  -c class (or	to the default parameter values	for the	process's cur-
       rent class if the -c class option is also omitted).

       In order	to change the scheduling parameters of a process using	prioc-
       ntl  the	 real or effective user	ID (respectively, groupID) of the user
       invoking	priocntl must match the	real or	 effective  user  ID  (respec-
       tively,	groupID)  of the receiving process or the effective user ID of
       the user	must be	super-user. These are the minimum permission  require-
       ments  enforced	for  all classes. An individual	class may impose addi-
       tional permissions requirements when setting processes to that class or
       when setting class-specific scheduling parameters.

       When idtype and idlist specify a	set of processes, priocntl acts	on the
       processes in the	set in an implementation-specific order.  If  priocntl
       encounters  an error for	one or more of the target processes, it	may or
       may not continue	through	the set	of processes, depending	on the	nature
       of the error.

       If  the	error is related to permissions, priocntl prints an error mes-
       sage and	then continues through the process set,	resetting the  parame-
       ters  for  all target processes for which the user has appropriate per-
       missions. If priocntl encounters	an error other	than  permissions,  it
       does  not  continue through the process set but prints an error message
       and exits immediately.

       A special sys scheduling	class exists for the purpose of	scheduling the
       execution  of  certain  special	system	processes (such	as the swapper
       process). It is not possible to change the class	of any process to sys.
       In  addition,  any  processes in	the sys	class that are included	in the
       set of processes	specified by idtype and	idlist are disregarded by pri-
       ocntl.  For example, if idtype were uid,	an idlist consisting of	a zero
       would specify all processes with	a UID of 0, except  processes  in  the
       sys class and (if changing the parameters using the -s option) the init
       process.

       The init	process	(process ID 1) is a special case.  In  order  for  the
       priocntl	 command to change the class or	other scheduling parameters of
       the init	process, idtype	must be	pid and	idlist must be consist of only
       a  1.  The  init	process	may be assigned	to any class configured	on the
       system, but the time-sharing class is  almost  always  the  appropriate
       choice. (Other choices may be highly undesirable; see the System	Admin-
       istration Guide:	Basic Administration for more information.)

       The command

       priocntl	-e [-c class] [class-specific options] command \
	    [argument...]

       executes	the specified command with the class and scheduling parameters
       specified  on the command line (arguments are the arguments to the com-
       mand). If the -c	class option is	omitted	the  command  is  run  in  the
       user's current class.

OPTIONS
       The following options are supported:

       -c class
	     Specifies	the class to be	set. (The valid	class arguments	are RT
	     for real-time, TS for time-sharing, IA for	inter-active, FSS  for
	     fair-share,  or FX	for fixed-priority.) If	the specified class is
	     not already configured, it	will be	automatically configured.

       -d    Displays the scheduling parameters	associated with	a set of  pro-
	     cesses.

       -e    Executes a	specified command with the class and scheduling	param-
	     eters associated with a set of processes.

       -i idtype
	     This option, together with	the idlist arguments (if any),	speci-
	     fies  one	or  more processes to which the	priocntl command is to
	     apply. The	interpretation of idlist depends on the	value  of  id-
	     type.  The	 valid	idtype arguments and corresponding interpreta-
	     tions of idlist are as follows:

	     -i	pid
		   idlist is a list of process IDs. The	priocntl  command  ap-
		   plies to the	specified processes.

	     -i	ppid
		   idlist  is  a list of parent	process	IDs. The priocntl com-
		   mand	applies	to all processes whose parent process ID is in
		   the list.

	     -i	pgid
		   idlist is a list of process group IDs. The priocntl command
		   applies to all processes in the specified process groups.

	     -i	sid
		   idlist is a list of session IDs. The	priocntl  command  ap-
		   plies to all	processes in the specified sessions.

	     -i	taskid
		   idlist  is a	list of	task IDs. The priocntl command applies
		   to all processes in the specified tasks.

	     -i	class
		   idlist consists of a	single class name (RT  for  real-time,
		   TS  for  time-sharing,  IA  for inter-active, FSS for fair-
		   share, or FX	for fixed-priority). The priocntl command  ap-
		   plies to all	processes in the specified class.

	     -i	uid
		   idlist  is a	list of	user IDs. The priocntl command applies
		   to all processes with an effective user ID equal to	an  ID
		   from	the list.

	     -i	gid
		   idlist is a list of group IDs. The priocntl command applies
		   to all processes with an effective group ID equal to	an  ID
		   from	the list.

	     -i	projid
		   idlist  is  a list of project IDs. The priocntl command ap-
		   plies to all	processes with an effective project  ID	 equal
		   to an ID from the list.

	     -i	all
		   The	priocntl command applies to all	existing processes. No
		   idlist should be specified (if one is specified, it is  ig-
		   nored).  The	 permission restrictions described below still
		   apply.

	     If	the -i idtype option is	omitted	when using the -d  or  -s  op-
	     tions the default idtype of pid is	assumed.

       -l    Displays a	list of	the classes currently configured in the	system
	     along with	class-specific information about each class. The  for-
	     mat  of the class-specific	information displayed is described un-
	     der USAGE.

       -s    Sets the scheduling parameters associated	with  a	 set  of  pro-
	     cesses.

       The valid class-specific	options	for setting real-time parameters are:

       -p rtpri
	     Sets  the	real-time priority of the specified process(es)	to rt-
	     pri.

       -t tqntm	[-r res]
	     Sets the time quantum of the specified process(es)	to tqntm.  You
	     may optionally specify a resolution as explained below.

       -q tqsig
	     Sets   the	  real-time  time  quantum  signal  of	the  specified
	     process(es) to tqsig.

       The valid class-specific	options	for  setting  time-sharing  parameters
       are:

       -m tsuprilim
	     Sets  the	user  priority	limit  of the specified	process(es) to
	     tsuprilim.

       -p tsupri
	     Sets the user priority of the specified process(es) to tsupri.

       The valid class-specific	options	for  setting  inter-active  parameters
       are:

       -m iauprilim
	     Sets  the	user  priority	limit  of the specified	process(es) to
	     iauprilim.

       -p iaupri
	     Sets the user priority of the specified process(es) to iaupri.

       The valid class-specific	options	for setting fair-share parameters are:

       -m fssuprilim
	     Sets the user priority limit of the specified process(es) to  fs-
	     suprilim.

       -p fssupri
	     Sets the user priority of the specified process(es) to fssupri.

       The  valid class-specific options for setting fixed-priority parameters
       are:

	      -m fxuprilim
		    Sets the user priority limit of the	specified  process(es)
		    to fxuprilim.

	      -p fxupri
		    Sets the user priority of the specified process(es)	to fx-
		    upri.

	      -t tqntm
		    [-r	 res]  Sets  the  time	quantum	  of   the   specified
		    process(es)	to tqntm. You may optionally specify a resolu-
		    tion as explained below.

USAGE
   Real-Time Class
       The real-time class provides a  fixed  priority	preemptive  scheduling
       policy  for  those  processes requiring fast and	deterministic response
       and absolute user/application control of	scheduling priorities. If  the
       real-time  class	 is configured in the system, it should	have exclusive
       control of the highest range of scheduling priorities  on  the  system.
       This ensures that a runnable real-time process is given CPU service be-
       fore any	process	belonging to any other class.

       The real-time class has a range of real-time  priority  (rtpri)	values
       that  may  be assigned to processes within the class. Real-time priori-
       ties range from 0 to x, where the value of x is configurable and	can be
       displayed  for  a  specific  installation that has already configured a
       real-time scheduler, by using the command

       priocntl	-l

       The real-time scheduling	policy is a fixed priority policy. The	sched-
       uling  priority	of a real-time process never changes except as the re-
       sult of an explicit request by the user/application to change the rtpri
       value of	the process.

       For processes in	the real-time class, the rtpri value is, for all prac-
       tical purposes, equivalent to the scheduling priority of	 the  process.
       The  rtpri  value  completely  determines  the scheduling priority of a
       real-time process relative to other processes within its	class. Numeri-
       cally  higher rtpri values represent higher priorities. Since the real-
       time class controls the highest range of	scheduling priorities  in  the
       system,	it  is guaranteed that the runnable real-time process with the
       highest rtpri value is always selected to run before any	other  process
       in the system.

       In  addition  to	providing control over priority, priocntl provides for
       control over the	length of the time quantum allotted  to	 processes  in
       the  real-time  class.  The  time  quantum  value specifies the maximum
       amount of time a	process	may run, assuming that it does not complete or
       enter  a	 resource  or event wait state (sleep).	Notice that if another
       process becomes runnable	at a higher priority,  the  currently  running
       process may be preempted	before receiving its full time quantum.

       The command

       priocntl	-d [-i idtype] [idlist]

       displays	 the  real-time	priority, time quantum (in millisecond resolu-
       tion), and time quantum signal value for	each real-time process in  the
       set specified by	idtype and idlist.

       Any  combination	 of  the  -p, -t [-r], and -q options may be used with
       priocntl	-s or priocntl -e for the real-time class.  If	an  option  is
       omitted	and the	process	is currently real-time,	the associated parame-
       ter is unaffected. If an	option is omitted when changing	the class of a
       process to real-time from some other class, the associated parameter is
       set to a	default	value. The default value for rtpri is 0	 and  the  de-
       fault  for  time	 quantum is dependent on the value of rtpri and	on the
       system configuration; see rt_dptbl(4).

       When using the -t tqntm option, you may optionally specify a resolution
       using  the  -r  res option. (If no resolution is	specified, millisecond
       resolution is assumed.) If res is specified, it must be a positive  in-
       teger  between  1 and 1,000,000,000 inclusively and the resolution used
       is the reciprocal of res	in seconds. For	example, specifying -t	10  -r
       100  would set the resolution to	hundredths of a	second and the result-
       ing time	quantum	length would be	10/100 seconds (one tenth  of  a  sec-
       ond).  Although very fine (nanosecond) resolution may be	specified, the
       time quantum length is rounded up by the	system to  the	next  integral
       multiple	  of the system	clock's	resolution. Requests for time quantums
       of zero or quantums greater than	the (typically very large) implementa-
       tion-specific maximum quantum result in an error.

       The  real-time  time quantum signal can be used to notify runaway real-
       time processes about the	consumption of their time quantum. Those  pro-
       cesses,	which  are monitored by	the real-time time quantum signal, re-
       ceive the configured signal in the event	of  time  quantum  expiration.
       The  default  value (0) of the time quantum signal tqsig	will denote no
       signal delivery.	A positive value will denote the delivery of the  sig-
       nal  specified  by the value. Like kill(1) and other commands operating
       on signals, the -q tqsig	option is also	able  to  handle  symbolically
       named signals, like XCPU	or KILL.

       In  order to change the class of	a process to real-time (from any other
       class), the user	invoking priocntl must have super-user	privilege.  In
       order to	change the rtpri value or time quantum of a real-time process,
       the user	invoking priocntl must either be super-user, or	must currently
       be in the real-time class (shell	running	as a real-time process)	with a
       real or effective user ID matching the real or effective	user ID	of the
       target process.

       The  real-time  priority, time quantum, and time	quantum	signal are in-
       herited across the fork(2) and exec(2) system  calls.  When  using  the
       time  quantum  signal  with  a  user  defined signal handler across the
       exec(2) system call, the	new image must install an appropriate user de-
       fined  signal  handler  before the time quantum expires.	Otherwise, un-
       predicable behavior would result.

   Time-Sharing	Class
       The time-sharing	scheduling policy provides for a  fair	and  effective
       allocation  of  the  CPU	resource among processes with varying CPU con-
       sumption	characteristics. The objectives	of the time-sharing policy are
       to  provide  good  response  time  to  interactive  processes  and good
       throughput to CPU-bound jobs, while providing a degree of user/applica-
       tion control over scheduling.

       The  time-sharing  class	 has  a	 range	of  time-sharing user priority
       (tsupri)	values that may	be assigned to	processes  within  the	class.
       User  priorities	 range	from -x	to +x, where the value of x is config-
       urable. The range for a specific	installation can be displayed by using
       the command

       priocntl	-l

       The  purpose of the user	priority is to provide some degree of user/ap-
       plication control over the scheduling of	processes in the  time-sharing
       class.  Raising	or lowering the	tsupri value of	a process in the time-
       sharing class raises or lowers the scheduling priority of the  process.
       It  is  not  guaranteed,	 however,  that	 a time-sharing	process	with a
       higher tsupri value will	run before one with a lower tsupri value. This
       is  because  the	 tsupri	value is just one factor used to determine the
       scheduling priority of a	time-sharing process. The system  may  dynami-
       cally adjust the	internal scheduling priority of	a time-sharing process
       based on	other factors such as recent CPU usage.

       In addition to the system-wide limits on	user priority (displayed  with
       priocntl	 -l),  there is	a per process user priority limit (tsuprilim),
       which specifies the maximum tsupri value	that may be set	 for  a	 given
       process.

       The command

       priocntl	-d [-i idtype] [idlist]

       displays	 the user priority and user priority limit for each time-shar-
       ing process in the set specified	by idtype and idlist.

       Any time-sharing	process	may lower its own tsuprilim (or	 that  of  an-
       other  process with the same user ID). Only a time-sharing process with
       super-user privilege may	raise a	tsuprilim. When	changing the class  of
       a  process  to time-sharing from	some other class, super-user privilege
       is required in order to set the initial tsuprilim to  a	value  greater
       than zero.

       Any  time-sharing  process  may	set its	own tsupri (or that of another
       process with the	same user ID) to any value less	than or	equal  to  the
       process's  tsuprilim.  Attempts	to  set	the tsupri above the tsuprilim
       (and/or set the tsuprilim below the tsupri) result in the tsupri	 being
       set equal to the	tsuprilim.

       Any  combination	 of the	-m and -p options may be used with priocntl -s
       or priocntl -e for the time-sharing class. If an	option is omitted  and
       the process is currently	time-sharing, the associated parameter is nor-
       mally unaffected. The exception is when the -p option is	omitted	and -m
       is  used	to set a tsuprilim below the current tsupri. In	this case, the
       tsupri is set equal to the tsuprilim which is being set.	If  an	option
       is  omitted  when  changing the class of	a process to time-sharing from
       some other class, the associated	parameter is set to a  default	value.
       The  default  value for tsuprilim is 0 and the default for tsupri is to
       set it equal to the tsuprilim value which is being set.

       The time-sharing	user priority and user priority	 limit	are  inherited
       across the fork(2) and exec(2) system calls.

   Inter-Active	Class
       The  inter-active  scheduling  policy provides for a fair and effective
       allocation of the CPU resource among processes with  varying  CPU  con-
       sumption	 characteristics  while	providing good responsiveness for user
       interaction. The	objectives of the inter-active policy are  to  provide
       good response time to interactive processes and good throughput to CPU-
       bound jobs. The priorities of processes in the inter-active  class  can
       be  changed  in	the  same  manner  as those in the time-sharing	class,
       though the modified priorities will continue to be adjusted to  provide
       good responsiveness for user interaction.

       The  inter-active user priority limit, iaupri, is equivalent to tsupri.
       The inter-active	per process user priority, iauprilim, is equivalent to
       tsuprilim.

       Inter-active  class processes that have the iamode ("interactive	mode")
       bit set are given a priority boost value	of 10, which is	factored  into
       the  user  mode	priority of the	process	when that calculation is made,
       that is,	every time a process's priority	is adjusted. This  feature  is
       used by the X windowing system, which sets this bit for those processes
       that run	inside of the current active window to give them a higher pri-
       ority.

   Fair-Share Class
       The  fair-share	scheduling policy provides a fair allocation of	system
       CPU resources among projects, independent of the	 number	 of  processes
       they  own.  Projects are	given "shares" to control their	entitlement to
       CPU resources. Resource usage is	remembered over	time, so that entitle-
       ment  is	 reduced  for heavy usage, and increased for light usage, with
       respect to other	projects. CPU time is scheduled	 among	processes  ac-
       cording	to  their  owner's  entitlements, independent of the number of
       processes each project owns.

       The FSS scheduling class	supports the notion of per-process user	prior-
       ity  and	 user  priority	 limit	for  compatibility with	the time-share
       scheduler. The fair share  scheduler  attempts  to  provide  an	evenly
       graded effect across the	whole range of user priorities.	Processes with
       positive	fssupri	values receive time slices less	frequently  than  nor-
       mal,   while  negative  nice  processes	receive	time slices more  fre-
       quently than normal.  Notice that user priorities do not	interfere with
       shares.	That is, changing a fssupri value of a process is not going to
       affect its project's overall CPU	usage which only relates to the	amount
       of shares it is allocated compared to other projects.

       The  priorities	of processes in	the fair-share class can be changed in
       the same	manner as those	in the time-share class.

   Fixed-Priority Class
       The fixed-priority class	provides a fixed priority preemptive  schedul-
       ing policy for those processes requiring	that the scheduling priorities
       do not get dynamically adjusted by the system and that the  user/appli-
       cation have control of the scheduling priorities.

       The fixed-priority class	shares the same	range of scheduling priorities
       with the	time-sharing class, by default.	The fixed-priority class has a
       range  of  fixed-priority user priority (fxupri)	values that may	be as-
       signed to processes within the class. User priorities range from	 0  to
       x,  where  the value of x is configurable. The range for	a specific in-
       stallation can be displayed by using the	command

       priocntl	-l

       The purpose of the user priority	is to provide user/application control
       over  the scheduling of processes in the	fixed-priority class. For pro-
       cesses in the fixed-priority class, the fxupri value is,	for all	 prac-
       tical  purposes,	equivalent  to the scheduling priority of the process.
       The fxupri value	completely determines the  scheduling  priority	 of  a
       fixed-priority  process	relative  to other processes within its	class.
       Numerically higher fxupri values	represent higher priorities.

       In addition to the system-wide limits on	user priority (displayed  with
       priocntl	 -l), there is a per process user priority  limit (fxuprilim),
       which specifies the maximum fxupri value	that may be set	 for  a	 given
       process.

       Any  fixed-priority process may lower its own fxuprilim (or that	of an-
       other process with the same user	ID). Only a  process  with  super-user
       privilege  may  raise a fxuprilim. When changing	the class of a process
       to fixed-priority from some other class,	super-user  privilege  is  re-
       quired  in  order  to set the initial fxuprilim to a value greater than
       zero.

       Any fixed-priority process may set its own fxupri (or that  of  another
       process	with  the same user ID)	to any value less than or equal	to the
       process's fxuprilim. Attempts to	set the	 fxupri	 above	the  fxuprilim
       (and/or	set the	fxuprilim below	the fxupri) result in the fxupri being
       set equal to the	fxuprilim.

       In addition to providing	control	over priority, priocntl	 provides  for
       control	over  the  length of the time quantum allotted to processes in
       the fixed-priority class. The time quantum value	specifies the  maximum
       amount of time a	process	may run, before	surrendering the CPU, assuming
       that it does not	complete or enter  a  resource	or  event  wait	 state
       (sleep).	 Notice	 that  if another process becomes runnable at a	higher
       priority, the currently running process may be preempted	before receiv-
       ing its full time quantum.

       Any combination of the -m, -p, and -t options may be used with priocntl
       -s or priocntl -e for the fixed-priority	class. If an option is omitted
       and  the	 process is currently fixed-priority, the associated parameter
       is normally unaffected. The exception is	when the -p option is  omitted
       and  the	-m option is used to set a fxuprilim below the current fxupri.
       In this case, the fxupri	is set equal to	the fxuprilim which  is	 being
       set.  If	 an  option is omitted when changing the class of a process to
       fixed-priority from some	other class, the associated parameter  is  set
       to  a  default value. The default value for fxuprilim is	0. The default
       for fxupri is to	set it equal to	the fxuprilim  value  which  is	 being
       set. The	default	for time quantum is dependent on the fxupri and	on the
       system configuration. See fx_dptbl( 4).

       The time	quantum	of processes in	the fixed-priority class       can  be
       changed in the same manner as those in the real-time class.

       The fixed-priority user priority, user priority limit, and time quantum
       are inherited across the	fork(2)	and exec(2) system calls.

EXAMPLES
       Real-Time Class examples	follow:

       Example 1: Setting the class of any non-real-time processes

       This example sets the class of any non-real-time	processes selected  by
       idtype and idlist to real-time and sets their real-time priority	to the
       default value of	0. The real-time priorities of any processes currently
       in  the real-time class are unaffected. The time	quantums of all	of the
       specified processes are set to 1/10 seconds.

       example%	priocntl -s -c RT -t 1 -r 10 -i	idtype idlist

       Example 2: Executing a command in real-time

       This example executes command in	the real-time class with  a  real-time
       priority	of 15 and a time quantum of 20 milliseconds:

       example%	priocntl -e -c RT -p 15	-t 20 command

       Example	3:  Executing  a command in real-time with a specified quantum
       signal

       This example executes command in	the real-time class with  a  real-time
       priority	of 11, a time quantum of 250 milliseconds, and where the spec-
       ified real-time quantum signal is SIGXCPU:

       example%	priocntl -e -c RT -p 11	-t 250 -q XCPU command

       Time-Sharing Class examples follow:

       Example 4: Setting the class of non-time-sharing	processes

       This example sets the class of any non-time-sharing processes  selected
       by  idtype and idlist to	time-sharing and sets both their user priority
       limit and user priority to 0. Processes	already	 in  the  time-sharing
       class are unaffected.

       example%	priocntl -s -c TS -i idtype idlist

       Example 5: Executing a command in the time-sharing class

       This example executes command with the arguments	arguments in the time-
       sharing class with a user priority limit	of 0 and a  user  priority  of
       -15:

       example%	priocntl -e -c TS -m 0 -p -15 command [arguments]

       Example 6: Executing a command in fixed-priority	class

       This  example  executes	a  command in the fixed-priority  class	with a
       user priority limit of 20 and user priority of 10 and time  quantum  of
       250 milliseconds:

       example%	priocntl -e -c FX -m 20	-p 10 -t 250 command

EXIT STATUS
       The following exit values are returned:

       For options -d, -l, and -s:

       0     Successful	operation.

       1     Error condition.

       For option -e:

       Return  of  the	Exit Status of the executed command denotes successful
       operation. Otherwise,

       1     Command could not be executed at the specified priority.

ATTRIBUTES
       See attributes(5) for descriptions of the following attributes:

       +-----------------------------+-----------------------------+
       |      ATTRIBUTE	TYPE	     |	    ATTRIBUTE VALUE	   |
       +-----------------------------+-----------------------------+
       |Availability		     |SUNWcsu			   |
       +-----------------------------+-----------------------------+
       |CSI			     |Enabled			   |
       +-----------------------------+-----------------------------+

SEE ALSO
       kill(1),	nice(1), ps(1),	exec(2), fork(2), priocntl(2),	fx_dptbl(  4),
       rt_dptbl( 4), attributes(5), FSS(7)

       System Administration Guide: Basic Administration

DIAGNOSTICS
       priocntl	prints the following error messages:

       Process(es) not found
	     None of the specified processes exists.

       Specified processes from	different classes
	     The  -s  option is	being used to set parameters, the -c class op-
	     tion is not present, and processes	from more than one  class  are
	     specified.

       Invalid option or argument
	     An	unrecognized or	invalid	option or option argument is used.

SunOS 5.9			  28 Sep 2001			   priocntl(1)

NAME | SYNOPSIS | DESCRIPTION | OPTIONS | USAGE | EXAMPLES | EXIT STATUS | ATTRIBUTES | SEE ALSO | DIAGNOSTICS

Want to link to this manual page? Use this URL:
<https://www.freebsd.org/cgi/man.cgi?query=priocntl&sektion=1&manpath=SunOS+5.9>

home | help