1priocntl(1) User Commands priocntl(1)
2
3
4
6 priocntl - display or set scheduling parameters of specified
7 process(es)
8
10 priocntl -l
11
12
13 priocntl -d [-i idtype] [idlist]
14
15
16 priocntl -s [-c class] [class-specific options]
17 [-i idtype] [idlist]
18
19
20 priocntl -e [-c class] [class-specific options] command
21 [argument(s)]
22
23
25 The priocntl command displays or sets scheduling parameters of the
26 specified process(es). It can also be used to display the current con‐
27 figuration information for the system's process scheduler or execute a
28 command with specified scheduling parameters.
29
30
31 Processes fall into distinct classes with a separate scheduling policy
32 applied to each class. The process classes currently supported are the
33 real-time class, time-sharing class, interactive class, fair-share
34 class, and the fixed priority class. The characteristics of these
35 classes and the class-specific options they accept are described below
36 in the USAGE section under the headings Real-Time Class, Time-Sharing
37 Class, Inter-Active Class, Fair-Share Class, and Fixed-Priority Class.
38 With appropriate permissions, the priocntl command can change the class
39 and other scheduling parameters associated with a running process.
40
41
42 In the default configuration, a runnable real-time process runs before
43 any other process. Therefore, inappropriate use of real-time processes
44 can have a dramatic negative impact on system performance.
45
46
47 If an idlist is present, it must appear last on the command line and
48 the elements of the list must be separated by white space. If no idlist
49 is present, an idtype argument of pid, ppid, pgid, sid, taskid, class,
50 uid, gid, projid, or zoneid specifies the process ID, parent process
51 ID, process group ID, session ID, task ID, class, user ID, group ID,
52 project ID, or zone ID, respectively, of the priocntl command itself.
53
54
55 The command
56
57 priocntl -d [-i idtype] [idlist]
58
59
60
61
62 displays the class and class-specific scheduling parameters of the
63 process(es) specified by idtype and idlist.
64
65
66 The command
67
68 priocntl -s [-c class] [class-specific options] \
69 [-i idtype] [idlist]
70
71
72
73
74 sets the class and class-specific parameters of the specified processes
75 to the values given on the command line. The -c class option specifies
76 the class to be set. (The valid class arguments are RT for real-time,
77 TS for time-sharing, IA for inter-active, FSS for fair-share, or FX for
78 fixed-priority.)
79
80
81 The class-specific parameters to be set are specified by the class-spe‐
82 cific options as explained under the appropriate heading below. If the
83 -c class option is omitted, idtype and idlist must specify a set of
84 processes which are all in the same class, otherwise an error results.
85 If no class-specific options are specified, the process's class-spe‐
86 cific parameters are set to the default values for the class specified
87 by -c class (or to the default parameter values for the process's cur‐
88 rent class if the -c class option is also omitted).
89
90
91 In order to change the scheduling parameters of a process using prioc‐
92 ntl the real or effective user ID (respectively, groupID) of the user
93 invoking priocntl must match the real or effective user ID (respec‐
94 tively, groupID) of the receiving process or the effective user ID of
95 the user must be super-user. These are the minimum permission require‐
96 ments enforced for all classes. An individual class can impose addi‐
97 tional permissions requirements when setting processes to that class or
98 when setting class-specific scheduling parameters.
99
100
101 When idtype and idlist specify a set of processes, priocntl acts on the
102 processes in the set in an implementation-specific order. If priocntl
103 encounters an error for one or more of the target processes, it can or
104 cannot continue through the set of processes, depending on the nature
105 of the error.
106
107
108 If the error is related to permissions, priocntl prints an error mes‐
109 sage and then continues through the process set, resetting the parame‐
110 ters for all target processes for which the user has appropriate per‐
111 missions. If priocntl encounters an error other than permissions, it
112 does not continue through the process set but prints an error message
113 and exits immediately.
114
115
116 A special sys scheduling class exists for the purpose of scheduling the
117 execution of certain special system processes (such as the swapper
118 process). It is not possible to change the class of any process to sys.
119 In addition, any processes in the sys class that are included in the
120 set of processes specified by idtype and idlist are disregarded by pri‐
121 ocntl. For example, if idtype were uid, an idlist consisting of a zero
122 would specify all processes with a UID of 0, except processes in the
123 sys class and (if changing the parameters using the -s option) the init
124 process.
125
126
127 The init process (process ID 1) is a special case. In order for the
128 priocntl command to change the class or other scheduling parameters of
129 the init process, idtype must be pid and idlist must be consist of only
130 a 1. The init process can be assigned to any class configured on the
131 system, but the time-sharing class is almost always the appropriate
132 choice. Other choices can be highly undesirable; see the System Admin‐
133 istration Guide: Basic Administration for more information.
134
135
136 The command
137
138 priocntl -e [-c class] [class-specific options] command \
139 [argument...]
140
141
142
143
144 executes the specified command with the class and scheduling parameters
145 specified on the command line (arguments are the arguments to the com‐
146 mand). If the -c class option is omitted the command is run in the
147 user's current class.
148
150 The following options are supported:
151
152 -c class Specifies the class to be set. (The valid class arguments
153 are RT for real-time, TS for time-sharing, IA for inter-
154 active, FSS for fair-share, or FX for fixed-priority.) If
155 the specified class is not already configured, it is auto‐
156 matically configured.
157
158
159 -d Displays the scheduling parameters associated with a set
160 of processes.
161
162
163 -e Executes a specified command with the class and scheduling
164 parameters associated with a set of processes.
165
166
167 -i idtype This option, together with the idlist arguments (if any),
168 specifies one or more processes to which the priocntl com‐
169 mand is to apply. The interpretation of idlist depends on
170 the value of idtype. If the -i idtype option is omitted
171 when using the -d or -s options the default idtype of pid
172 is assumed.
173
174 The valid idtype arguments and corresponding interpreta‐
175 tions of idlist are as follows:
176
177 -i all The priocntl command applies to all existing
178 processes. No idlist should be specified (if
179 one is specified, it is ignored). The permis‐
180 sion restrictions described below still
181 apply.
182
183
184 -i ctid idlist is a list of process contract IDs. The
185 priocntl command applies to all processes
186 with a process contract ID equal to an ID
187 from the list.
188
189
190 -i class idlist consists of a single class name (RT
191 for real-time, TS for time-sharing, IA for
192 inter-active, FSS for fair-share, or FX for
193 fixed-priority). The priocntl command applies
194 to all processes in the specified class.
195
196
197 -i gid idlist is a list of group IDs. The priocntl
198 command applies to all processes with an
199 effective group ID equal to an ID from the
200 list.
201
202
203 -i pgid idlist is a list of process group IDs. The
204 priocntl command applies to all processes in
205 the specified process groups.
206
207
208 -i pid idlist is a list of process IDs. The priocntl
209 command applies to the specified processes.
210
211
212 -i ppid idlist is a list of parent process IDs. The
213 priocntl command applies to all processes
214 whose parent process ID is in the list.
215
216
217 -i projid idlist is a list of project IDs. The priocntl
218 command applies to all processes with an
219 effective project ID equal to an ID from the
220 list.
221
222
223 -i sid idlist is a list of session IDs. The priocntl
224 command applies to all processes in the spec‐
225 ified sessions.
226
227
228 -i taskid idlist is a list of task IDs. The priocntl
229 command applies to all processes in the spec‐
230 ified tasks.
231
232
233 -i uid idlist is a list of user IDs. The priocntl
234 command applies to all processes with an
235 effective user ID equal to an ID from the
236 list.
237
238
239 -i zoneid idlist is a list of zone IDs. The priocntl
240 command applies to all processes with an
241 effective zone ID equal to an ID from the
242 list.
243
244
245
246 -l Displays a list of the classes currently configured in the
247 system along with class-specific information about each
248 class. The format of the class-specific information dis‐
249 played is described under USAGE.
250
251
252 -s Sets the scheduling parameters associated with a set of
253 processes.
254
255
256
257 The valid class-specific options for setting real-time parameters are:
258
259 -p rtpri Sets the real-time priority of the specified
260 process(es) to rtpri.
261
262
263 -t tqntm [-r res] Sets the time quantum of the specified process(es)
264 to tqntm. You can optionally specify a resolution
265 as explained below.
266
267
268 -q tqsig Sets the real-time time quantum signal of the
269 specified process(es) to tqsig.
270
271
272
273 The valid class-specific options for setting time-sharing parameters
274 are:
275
276 -m tsuprilim Sets the user priority limit of the specified
277 process(es) to tsuprilim.
278
279
280 -p tsupri Sets the user priority of the specified process(es) to
281 tsupri.
282
283
284
285 The valid class-specific options for setting inter-active parameters
286 are:
287
288 -m iauprilim Sets the user priority limit of the specified
289 process(es) to iauprilim.
290
291
292 -p iaupri Sets the user priority of the specified process(es) to
293 iaupri.
294
295
296
297 The valid class-specific options for setting fair-share parameters are:
298
299 -m fssuprilim Sets the user priority limit of the specified
300 process(es) to fssuprilim.
301
302
303 -p fssupri Sets the user priority of the specified process(es) to
304 fssupri.
305
306
307
308 The valid class-specific options for setting fixed-priority parameters
309 are:
310
311 -m fxuprilim Sets the user priority limit of the specified
312 process(es) to fxuprilim.
313
314
315 -p fxupri Sets the user priority of the specified process(es) to
316 fxupri.
317
318
319 -t tqntm [-r res] Sets the time quantum of the specified
320 process(es) to tqntm. You can optionally specify a res‐
321 olution as explained below.
322
323
325 Real-Time Class
326 The real-time class provides a fixed priority preemptive scheduling
327 policy for those processes requiring fast and deterministic response
328 and absolute user/application control of scheduling priorities. If the
329 real-time class is configured in the system, it should have exclusive
330 control of the highest range of scheduling priorities on the system.
331 This ensures that a runnable real-time process is given CPU service
332 before any process belonging to any other class.
333
334
335 The real-time class has a range of real-time priority (rtpri) values
336 that can be assigned to processes within the class. Real-time priori‐
337 ties range from 0 to x, where the value of x is configurable and can be
338 displayed for a specific installation that has already configured a
339 real-time scheduler, by using the command
340
341 priocntl -l
342
343
344
345
346 The real-time scheduling policy is a fixed priority policy. The sched‐
347 uling priority of a real-time process never changes except as the
348 result of an explicit request by the user/application to change the
349 rtpri value of the process.
350
351
352 For processes in the real-time class, the rtpri value is, for all prac‐
353 tical purposes, equivalent to the scheduling priority of the process.
354 The rtpri value completely determines the scheduling priority of a
355 real-time process relative to other processes within its class. Numeri‐
356 cally higher rtpri values represent higher priorities. Since the real-
357 time class controls the highest range of scheduling priorities in the
358 system, it is guaranteed that the runnable real-time process with the
359 highest rtpri value is always selected to run before any other process
360 in the system.
361
362
363 In addition to providing control over priority, priocntl provides for
364 control over the length of the time quantum allotted to processes in
365 the real-time class. The time quantum value specifies the maximum
366 amount of time a process can run, assuming that it does not complete or
367 enter a resource or event wait state (sleep). Notice that if another
368 process becomes runnable at a higher priority, the currently running
369 process can be preempted before receiving its full time quantum.
370
371
372 The command
373
374 priocntl -d [-i idtype] [idlist]
375
376
377
378
379 displays the real-time priority, time quantum (in millisecond resolu‐
380 tion), and time quantum signal value for each real-time process in the
381 set specified by idtype and idlist.
382
383
384 Any combination of the -p, -t [-r], and -q options can be used with
385 priocntl -s or priocntl -e for the real-time class. If an option is
386 omitted and the process is currently real-time, the associated parame‐
387 ter is unaffected. If an option is omitted when changing the class of a
388 process to real-time from some other class, the associated parameter is
389 set to a default value. The default value for rtpri is 0 and the
390 default for time quantum is dependent on the value of rtpri and on the
391 system configuration; see rt_dptbl(4).
392
393
394 When using the -t tqntm option, you can optionally specify a resolution
395 using the -r res option. (If no resolution is specified, millisecond
396 resolution is assumed.) If res is specified, it must be a positive
397 integer between 1 and 1,000,000,000 inclusively and the resolution used
398 is the reciprocal of res in seconds. For example, specifying -t 10 -r
399 100 would set the resolution to hundredths of a second and the result‐
400 ing time quantum length would be 10/100 seconds (one tenth of a sec‐
401 ond). Although very fine (nanosecond) resolution can be specified, the
402 time quantum length is rounded up by the system to the next integral
403 multiple of the system clock's resolution. Requests for time quantums
404 of zero or quantums greater than the (typically very large) implementa‐
405 tion-specific maximum quantum result in an error.
406
407
408 The real-time time quantum signal can be used to notify runaway real-
409 time processes about the consumption of their time quantum. Those pro‐
410 cesses, which are monitored by the real-time time quantum signal,
411 receive the configured signal in the event of time quantum expiration.
412 The default value (0) of the time quantum signal tqsig denotes no sig‐
413 nal delivery. A positive value denotes the delivery of the signal spec‐
414 ified by the value. Like kill(1) and other commands operating on sig‐
415 nals, the -q tqsig option is also able to handle symbolically named
416 signals, like XCPU or KILL.
417
418
419 In order to change the class of a process to real-time (from any other
420 class), the user invoking priocntl must have super-user privilege. In
421 order to change the rtpri value or time quantum of a real-time process,
422 the user invoking priocntl must either be super-user, or must currently
423 be in the real-time class (shell running as a real-time process) with a
424 real or effective user ID matching the real or effective user ID of the
425 target process.
426
427
428 The real-time priority, time quantum, and time quantum signal are
429 inherited across the fork(2) and exec(2) system calls. When using the
430 time quantum signal with a user defined signal handler across the
431 exec(2) system call, the new image must install an appropriate user
432 defined signal handler before the time quantum expires. Otherwise,
433 unpredicable behavior would result.
434
435 Time-Sharing Class
436 The time-sharing scheduling policy provides for a fair and effective
437 allocation of the CPU resource among processes with varying CPU con‐
438 sumption characteristics. The objectives of the time-sharing policy are
439 to provide good response time to interactive processes and good
440 throughput to CPU-bound jobs, while providing a degree of user/applica‐
441 tion control over scheduling.
442
443
444 The time-sharing class has a range of time-sharing user priority
445 (tsupri) values that can be assigned to processes within the class.
446 User priorities range from −x to +x, where the value of x is config‐
447 urable. The range for a specific installation can be displayed by using
448 the command
449
450 priocntl -l
451
452
453
454
455 The purpose of the user priority is to provide some degree of
456 user/application control over the scheduling of processes in the time-
457 sharing class. Raising or lowering the tsupri value of a process in the
458 time-sharing class raises or lowers the scheduling priority of the
459 process. It is not guaranteed, however, that a time-sharing process
460 with a higher tsupri value runs before one with a lower tsupri value.
461 This is because the tsupri value is just one factor used to determine
462 the scheduling priority of a time-sharing process. The system can
463 dynamically adjust the internal scheduling priority of a time-sharing
464 process based on other factors such as recent CPU usage.
465
466
467 In addition to the system-wide limits on user priority (displayed with
468 priocntl -l), there is a per process user priority limit (tsuprilim),
469 which specifies the maximum tsupri value that can be set for a given
470 process.
471
472
473 The command
474
475 priocntl -d [-i idtype] [idlist]
476
477
478
479
480 displays the user priority and user priority limit for each time-shar‐
481 ing process in the set specified by idtype and idlist.
482
483
484 Any time-sharing process can lower its own tsuprilim (or that of
485 another process with the same user ID). Only a time-sharing process
486 with super-user privilege can raise a tsuprilim. When changing the
487 class of a process to time-sharing from some other class, super-user
488 privilege is required in order to set the initial tsuprilim to a value
489 greater than zero.
490
491
492 Any time-sharing process can set its own tsupri (or that of another
493 process with the same user ID) to any value less than or equal to the
494 process's tsuprilim. Attempts to set the tsupri above the tsuprilim
495 (and/or set the tsuprilim below the tsupri) result in the tsupri being
496 set equal to the tsuprilim.
497
498
499 Any combination of the -m and -p options can be used with priocntl -s
500 or priocntl -e for the time-sharing class. If an option is omitted and
501 the process is currently time-sharing, the associated parameter is nor‐
502 mally unaffected. The exception is when the -p option is omitted and -m
503 is used to set a tsuprilim below the current tsupri. In this case, the
504 tsupri is set equal to the tsuprilim which is being set. If an option
505 is omitted when changing the class of a process to time-sharing from
506 some other class, the associated parameter is set to a default value.
507 The default value for tsuprilim is 0 and the default for tsupri is to
508 set it equal to the tsuprilim value which is being set.
509
510
511 The time-sharing user priority and user priority limit are inherited
512 across the fork(2) and exec(2) system calls.
513
514 Inter-Active Class
515 The inter-active scheduling policy provides for a fair and effective
516 allocation of the CPU resource among processes with varying CPU con‐
517 sumption characteristics while providing good responsiveness for user
518 interaction. The objectives of the inter-active policy are to provide
519 good response time to interactive processes and good throughput to CPU-
520 bound jobs. The priorities of processes in the inter-active class can
521 be changed in the same manner as those in the time-sharing class,
522 though the modified priorities continue to be adjusted to provide good
523 responsiveness for user interaction.
524
525
526 The inter-active user priority limit, iaupri, is equivalent to tsupri.
527 The inter-active per process user priority, iauprilim, is equivalent to
528 tsuprilim.
529
530
531 Inter-active class processes that have the iamode ("interactive mode")
532 bit set are given a priority boost value of 10, which is factored into
533 the user mode priority of the process when that calculation is made,
534 that is, every time a process's priority is adjusted. This feature is
535 used by the X windowing system, which sets this bit for those processes
536 that run inside of the current active window to give them a higher pri‐
537 ority.
538
539 Fair-Share Class
540 The fair-share scheduling policy provides a fair allocation of system
541 CPU resources among projects, independent of the number of processes
542 they own. Projects are given "shares" to control their entitlement to
543 CPU resources. Resource usage is remembered over time, so that entitle‐
544 ment is reduced for heavy usage, and increased for light usage, with
545 respect to other projects. CPU time is scheduled among processes
546 according to their owner's entitlements, independent of the number of
547 processes each project owns.
548
549
550 The FSS scheduling class supports the notion of per-process user prior‐
551 ity and user priority limit for compatibility with the time-share
552 scheduler. The fair share scheduler attempts to provide an evenly
553 graded effect across the whole range of user priorities. Processes with
554 negative fssupri values receive time slices less frequently than nor‐
555 mal, while processes with positive fssupri values receive time slices
556 more frequently than normal. Notice that user priorities do not
557 interfere with shares. That is, changing a fssupri value of a process
558 is not going to affect its project's overall CPU usage which only
559 relates to the amount of shares it is allocated compared to other
560 projects.
561
562
563 The priorities of processes in the fair-share class can be changed in
564 the same manner as those in the time-share class.
565
566 Fixed-Priority Class
567 The fixed-priority class provides a fixed priority preemptive schedul‐
568 ing policy for those processes requiring that the scheduling priorities
569 do not get dynamically adjusted by the system and that the user/appli‐
570 cation have control of the scheduling priorities.
571
572
573 The fixed-priority class shares the same range of scheduling priorities
574 with the time-sharing class, by default. The fixed-priority class has a
575 range of fixed-priority user priority (fxupri) values that can be
576 assigned to processes within the class. User priorities range from 0 to
577 x, where the value of x is configurable. The range for a specific
578 installation can be displayed by using the command
579
580 priocntl -l
581
582
583
584
585 The purpose of the user priority is to provide user/application control
586 over the scheduling of processes in the fixed-priority class. For pro‐
587 cesses in the fixed-priority class, the fxupri value is, for all prac‐
588 tical purposes, equivalent to the scheduling priority of the process.
589 The fxupri value completely determines the scheduling priority of a
590 fixed-priority process relative to other processes within its class.
591 Numerically higher fxupri values represent higher priorities.
592
593
594 In addition to the system-wide limits on user priority (displayed with
595 priocntl -l), there is a per process user priority limit (fxuprilim),
596 which specifies the maximum fxupri value that can be set for a given
597 process.
598
599
600 Any fixed-priority process can lower its own fxuprilim (or that of
601 another process with the same user ID). Only a process with super-user
602 privilege can raise a fxuprilim. When changing the class of a process
603 to fixed-priority from some other class, super-user privilege is
604 required in order to set the initial fxuprilim to a value greater than
605 zero.
606
607
608 Any fixed-priority process can set its own fxupri (or that of another
609 process with the same user ID) to any value less than or equal to the
610 process's fxuprilim. Attempts to set the fxupri above the fxuprilim (or
611 set the fxuprilim below the fxupri) result in the fxupri being set
612 equal to the fxuprilim.
613
614
615 In addition to providing control over priority, priocntl provides for
616 control over the length of the time quantum allotted to processes in
617 the fixed-priority class. The time quantum value specifies the maximum
618 amount of time a process can run, before surrendering the CPU, assuming
619 that it does not complete or enter a resource or event wait state
620 (sleep). Notice that if another process becomes runnable at a higher
621 priority, the currently running process can be preempted before receiv‐
622 ing its full time quantum.
623
624
625 Any combination of the -m, -p, and -t options can be used with priocntl
626 -s or priocntl -e for the fixed-priority class. If an option is omitted
627 and the process is currently fixed-priority, the associated parameter
628 is normally unaffected. The exception is when the -p option is omitted
629 and the -m option is used to set a fxuprilim below the current fxupri.
630 In this case, the fxupri is set equal to the fxuprilim which is being
631 set. If an option is omitted when changing the class of a process to
632 fixed-priority from some other class, the associated parameter is set
633 to a default value. The default value for fxuprilim is 0. The default
634 for fxupri is to set it equal to the fxuprilim value which is being
635 set. The default for time quantum is dependent on the fxupri and on the
636 system configuration. See fx_dptbl(4).
637
638
639 The time quantum of processes in the fixed-priority class can be
640 changed in the same manner as those in the real-time class.
641
642
643 The fixed-priority user priority, user priority limit, and time quantum
644 are inherited across the fork(2) and exec(2) system calls.
645
647 The following are real-time class examples:
648
649 Example 1 Setting the Class
650
651
652 The following example sets the class of any non-real-time processes
653 selected by idtype and idlist to real-time and sets their real-time
654 priority to the default value of 0. The real-time priorities of any
655 processes currently in the real-time class are unaffected. The time
656 quantums of all of the specified processes are set to 1/10 seconds.
657
658
659 example% priocntl -s -c RT -t 1 -r 10 -i idtype idlist
660
661
662
663 Example 2 Executing a Command in Real-time
664
665
666 The following example executes command in the real-time class with a
667 real-time priority of 15 and a time quantum of 20 milliseconds:
668
669
670 example% priocntl -e -c RT -p 15 -t 20 command
671
672
673
674 Example 3 Executing a Command in Real-time with a Specified Quantum
675 Signal
676
677
678 The following example executes command in the real-time class with a
679 real-time priority of 11, a time quantum of 250 milliseconds, and where
680 the specified real-time quantum signal is SIGXCPU:
681
682
683 example% priocntl -e -c RT -p 11 -t 250 -q XCPU command
684
685
686
687
688 The following are time-sharing class examples:
689
690 Example 4 Setting the Class of non-time-sharing Processes
691
692
693 The following example sets the class of any non-time-sharing processes
694 selected by idtype and idlist to time-sharing and sets both their user
695 priority limit and user priority to 0. Processes already in the time-
696 sharing class are unaffected.
697
698
699 example% priocntl -s -c TS -i idtype idlist
700
701
702
703 Example 5 Executing a Command in the Time-sharing Class
704
705
706 The following example executes command with the arguments arguments in
707 the time-sharing class with a user priority limit of 0 and a user pri‐
708 ority of −15:
709
710
711 example% priocntl -e -c TS -m 0 -p -15 command [arguments]
712
713
714
715 Example 6 Executing a Command in Fixed-Priority Class
716
717
718 The following example executes a command in the fixed-priority class
719 with a user priority limit of 20 and user priority of 10 and time quan‐
720 tum of 250 milliseconds:
721
722
723 example% priocntl -e -c FX -m 20 -p 10 -t 250 command
724
725
726
728 The following exit values are returned:
729
730
731 For options -d, -l, and -s:
732
733 0 Successful operation.
734
735
736 1 Error condition.
737
738
739
740 For option -e:
741
742
743 Return of the Exit Status of the executed command denotes successful
744 operation. Otherwise,
745
746 1 Command could not be executed at the specified priority.
747
748
750 See attributes(5) for descriptions of the following attributes:
751
752
753
754
755 ┌─────────────────────────────┬─────────────────────────────┐
756 │ ATTRIBUTE TYPE │ ATTRIBUTE VALUE │
757 ├─────────────────────────────┼─────────────────────────────┤
758 │Availability │SUNWcsu │
759 ├─────────────────────────────┼─────────────────────────────┤
760 │CSI │Enabled │
761 └─────────────────────────────┴─────────────────────────────┘
762
764 kill(1), nice(1), ps(1), dispadmin(1M), exec(2), fork(2), priocntl(2),
765 fx_dptbl(4), process(4), rt_dptbl(4), attributes(5), zones(5), FSS(7)
766
767
768 System Administration Guide: Basic Administration
769
771 priocntl prints the following error messages:
772
773 Process(es) not found
774
775 None of the specified processes exists.
776
777
778 Specified processes from different classes
779
780 The -s option is being used to set parameters, the -c class option
781 is not present, and processes from more than one class are speci‐
782 fied.
783
784
785 Invalid option or argument
786
787 An unrecognized or invalid option or option argument is used.
788
789
790
791
792SunOS 5.11 1 Apr 2008 priocntl(1)