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

De man renice:

Les utilisateurs autres que le super-utilisateur ne peuvent modifier que la priorité des processus dont ils sont propriétaires et ne peuvent augmenter de manière monotone que leur `` valeur intéressante '' (pour des raisons de sécurité) dans la plage de 0 à PRIO_MAX (20) [...]

Donc, je peux renicemes propres processus vers le haut (leur donner une priorité inférieure) 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 utilisateurs normaux ne peuvent pas définir de bonnes valeurs inférieures à 0, mais pourquoi, puisque je peux réduire la priorité à 10, ne puis-je pas l'augmenter à nouveau à 9? Quelle «raison de sécurité» y a-t-il pour cela? J'ai le droit de lancer un processus avec une belle valeur de 9, alors pourquoi ne puis-je pas le remettre à 9?

EDIT: je devrais apprendre à faire défiler vers le bas. Il s'avère que cela est répertorié comme un bogue dans 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 renicecommande est apparue dans 4.0BSD qui, je pense, date de 1980. Cela devrait être très facile à corriger, donc d'une part ils semblent avoir choisi de la laisser et de l'autre ils la listent comme un bug.

nice priority terdon
la source

Parce que certaines priorités supérieures à 0 peuvent être appliquées par un processus système ou un module de sécurité et ne doivent jamais être diminuées par l'utilisateur (et il n'y a pas de contrôle suffisamment fin pour définir la gentillesse minimale d'un processus utilisateur donné autre que la valeur fixe 0) ? Pas une réponse car je ne suis pas sûr mais une supposition.

lgeorget

Même question sur askubuntu .

user202729

Réponses:

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

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

Une valeur de npour cette limite signifie qu'un processus sans la capacité CAP_NICE ne peut augmenter la priorité d'un processus que jusqu'à n, ce qui signifie diminuer la gentillesse jusqu'à une gentillesse de 20 - n. Ainsi, pour une valeur de 0, cela signifie qu'aucun utilisateur non privilégié ne peut réduire la gentillesse en dessous de 20, donc aucun utilisateur non privilégié ne peut réduire la gentillesse.

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

Il appartient à l'administrateur de choisir s'il autorise les utilisateurs à réduire leur priorité de processus et à quel niveau en fixant la limite stricte pour cela.

Pour savoir pourquoi un administrateur peut ne pas vouloir que les utilisateurs réduisent leur priorité de processus, voir la réponse de Flup .

Stéphane Chazelas
la source

Ah! C'est donc configurable! OK, cela a plus de sens, merci.

terdon

"valeurs de 0 à 40. [...] Vous remarquerez que la valeur par défaut est 20 sur Ubuntu 10.04 et 0 dans Debian Jessie par exemple." -> Les ulimits intéressants, durs / mous pour moi sont en effet 0 sur Debian Jessie. Je peux augmenter jusqu'à 20 mais au-delà de cela, j'obtiens "bash: ulimit: priorité de planification: ne peut pas modifier la limite: argument non valide", les valeurs négatives ne sont pas acceptées non plus.

thomanski

C'est pour ce que j'appellerais des raisons de politique . L'idée est que les utilisateurs normaux ne peuvent pas remplacer les actions des utilisateurs privilégiés.

Disons que vous êtes un utilisateur sur un énorme serveur partagé. Vous exécutez des processus monstrueux de monopolisation du processeur au détriment des autres utilisateurs. L'administrateur système utilise renicecertains de vos processus, car il ne vous aime pas beaucoup. Le système d'exploitation ne se souvient pas qui a fait le renice, mais il sait que les utilisateurs normaux ne peuvent pas inverser l'action. De cette façon, l'administrateur système contrôle les priorités de processus des utilisateurs normaux.

Flup
la source

Je peux comprendre cela, mais cela semble toujours étrange. En fait, je viens de réaliser qu'il est même répertorié comme un bogue dans man renice.

terdon

Je pense que le point du bug est que «les non super-utilisateurs ne peuvent pas augmenter les priorités de planification de leurs propres processus, même si ce sont eux qui ont diminué les priorités en premier lieu ». c'est-à-dire que c'est un effet secondaire de cette application qu'un accidentel renicene peut être inversé que par un utilisateur privilégié.

Flup

Parce que le système ne se souvient pas qui a défini la priorité. Idéalement, si vous augmentiez le niveau agréable et que vous vouliez ensuite l'abaisser, cela serait autorisé ... mais le système impose une interdiction générale précisément parce qu'il ne garde pas de trace de qui a fait quoi, de sorte que vous ne pouvez pas annuler un renicecela a rootfait.

Flup

@IwillnotexistIdonotexist pense aux systèmes avec de nombreux utilisateurs. Le sysadmin peut vouloir augmenter la priorité de vos processus à 5 et abaisser ceux du mien à 10. C'est toujours à la portée des utilisateurs normaux mais je ne serai pas en mesure de le changer et de voler le temps CPU que vous méritez. C'est l'idée de toute façon, comme Flup l'a expliqué. Cependant, comme StephaneChazelas l'a expliqué , c'est configurable, c'est donc au sysadmin de choisir ce qu'il préfère.

terdon

La réponse à «pourquoi?» Est tout simplement susceptible d'être «parce que personne n'en avait suffisamment besoin pour écrire le code pour le corriger». Lorsque Unix a été écrit à l'origine, le suivi de qui définissait la priorité d'un processus aurait pu être coûteux en termes de l'utilisation de la mémoire et le travail pour le mettre à jour, mais sur les machines modernes, c'est négligeable, laissant juste un manque de motivation pour écrire le code pour suivre cela pour les sites qui veulent garder la politique d'origine de "l'utilisateur ne peut pas remplacer sysadmin."

alanc

-1

Étrange? ça marche pour moi sur

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

2e édition

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

Changements de configuration

/etc/security/limits.conf

@audio          -       rtprio          100
@audio          -       nice            -10

Et je suis membre du groupe audio, c'était pour réduire la latence avec les xruns jack / ardour et buffer lors de l'enregistrement.

renice

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

X Tian
la source

Sur quelle distribution êtes-vous? il ne fonctionne pas sur AIX 6.2

Kiwy

Veuillez également publier la sortie de cat /etc/lsb*et renice --version.

terdon

renice --version renice from util-linux-ng 2.17.2mais toujours sous AIX ce n'est pas possible

Kiwy