Pourquoi ne puis-je pas utiliser renice pour augmenter la valeur d'un process?

De l' man renice :

Les users autres que le super-user ne peuvent que modifier la priorité des process qu'ils possèdent et ne peuvent qu'augmenter de façon monotone leur “ belle valeur '' (pour des raisons de security) comprise entre 0 et PRIO_MAX (20) […]

Ainsi, je peux renice mes propres process vers le haut (leur donner less de priorité) mais jamais vers le bas:

 $ renice 10 22316 22316 (process ID) old priority 0, new priority 10 $ renice 9 22316 renice: failed to set priority for 22316 (process ID): Permission denied 

Pourquoi est-ce? Je peux comprendre pourquoi les users normaux ne peuvent pas définir de belles valeurs inférieures à 0, mais pourquoi, puisque je peux diminuer la priorité à 10 je ne peux pas l'augmenter à 9? Quelle "raison de security" est là pour cela? J'ai le droit de lancer un process avec une belle valeur de 9, alors pourquoi ne puis-je pas le renier à 9?


EDIT: Je devrais apprendre à faire défiler vers le bas. Il s'avère que cela est répertorié comme un bug dans l' man renice :

 BUGS Non super-users can not increase scheduling priorities of their own processes, even if they were the ones that decreased the priorities in the first place. 

C'est encore plus déroutant. S'ils considèrent ce comportement comme un bug, pourquoi ne pas le changer? La command renice est apparue dans 4.0BSD qui je pense est de 1980. Cela devrait être très facile à corriger d'une part, ils semblent avoir choisi de le quitter et de l'autre, ils le répertorient comme un bug.

Depuis linux 2.6.12, cela dépend de la valeur de la limite ulimit -e ( ulimit -e ). Qui peut prendre des valeurs de 0 à 40. Cette limite est plus la limite sur la priorité du process (plus ce nombre est élevé, plus la priorité qu'un user peut définir pour un process).

Vous remarquerez que la valeur par défaut est 20 sur Ubuntu 10.04 et 0 dans Debian jessie par exemple.

Une valeur de n pour cette limite signifie qu'un process sans la capacité CAP_NICE peut seulement augmenter une priorité de process jusqu'à n , ce qui signifie diminuer la gentillesse jusqu'à une gentillesse de 20 - n . Donc, pour une valeur de 0, cela signifie qu'aucun user non privilégié ne peut baisser la gentillesse en dessous de 20, donc aucun user non privilégié ne peut baisser la gentillesse.

Avec une valeur de 20, les users non privilégiés peuvent ramener la gentillesse à 0.

C'est à l'administrateur de choisir s'ils permettent aux users de réduire leur priorité de process, et à quel niveau en définissant la limite ssortingcte pour cela.

Quant à savoir pourquoi un administrateur peut ne pas vouloir que les users abaissent leur priorité de process, voir la réponse de Flup .

C'est pour ce que j'appellerais des raisons politiques . L'idée est que les users normaux ne peuvent pas surcharger les actions des users privilégiés.

Disons que vous êtes un user sur un énorme server partagé. Vous courez des process monstrueux de CPU-hogging au désortingment des autres users. Le sysadmin renice certains de vos process parce qu'il ne vous aime pas beaucoup. L'OS ne se souvient pas de qui a fait le renice , mais il sait que les users normaux ne peuvent pas inverser l'action. De cette façon, le sysadmin contrôle les priorités de process des users normaux.

Étrange? ça marche pour moi

 Linux clafujiu 2.6.32-57-generic #119-Ubuntu \ SMP Wed Feb 19 01:04:55 UTC 2014 i686 GNU/Linux 

Exemple

 $ renice 8 --pid 21122 21122: old priority 9, new priority 8 christian@clafujiu:~/tmp$ ps eo "%p %n" PID NI 4190 0 8594 0 14684 0 21122 8 21146 0 21155 0 21209 0 christian@clafujiu:~/tmp$ renice 15 --pid 21122 21122: old priority 8, new priority 15 christian@clafujiu:~/tmp$ ps eo "%p %n" PID NI 4190 0 8594 0 14684 0 21122 15 21146 0 21155 0 21211 0 christian@clafujiu:~/tmp$ renice 10 --pid 21122 21122: old priority 15, new priority 10 christian@clafujiu:~/tmp$ ps eo "%p %n" PID NI 4190 0 8594 0 14684 0 21122 10 21146 0 21155 0 21213 0 

2ème édition

 $ cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=10.04 DISTRIB_CODENAME=lucid DISTRIB_DESCRIPTION="Ubuntu 10.04.4 LTS" 

Modifications de configuration

 /etc/security/limits.conf @audio - rtprio 100 @audio - nice -10 

Et je suis membre du groupe audio, cela a été de réduire la latence avec jack / ardor et buffer xruns lors de l'logging.

renice

 $ renice --version renice from util-linux-ng 2.17.2