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