Linux / Commande renice : modifier et vérifier le NI d’un processus

renice modifie la valeur de niceness d'un processus déjà lancé, alors que nice l'ajuste au démarrage d'une commande. Un nombre plus élevé rend généralement le processus moins favorable dans l'ordonnancement CPU. Vérifiez le PID, son propriétaire et son NI actuel avant une modification, puis contrôlez le résultat.

Distinguer valeur finale et ajustement

Ce guide concerne renice du paquet Linux util-linux. La forme classique sans -n utilise une valeur absolue :

renice valeur -p PID…

Ainsi, renice 10 -p PID demande une valeur finale 10, et non une addition de 10. C'est une différence essentielle avec nice -n et son ajustement relatif.

Ne supposez pas que -n a un sens universel. Le manuel util-linux décrit -n comme absolu par défaut, mais relatif lorsque la variable POSIXLY_CORRECT est définie. Les versions qui proposent --priority et --relative permettent d'exprimer explicitement ces deux intentions. Consultez renice --help et man renice sur votre machine avant de reprendre une de ces formes.

Examiner puis modifier un PID précis

Remplacez 1234 par un processus que vous êtes autorisé à modifier. Avec ps et sa colonne NI, vérifiez d'abord l'identité et la valeur :

ps -p 1234 -o pid,user,ni,cmd

Si la valeur finale 10 est adaptée à votre objectif et autorisée, l'action puis son contrôle s'écrivent :

renice 10 -p 1234
ps -p 1234 -o pid,ni,cmd

Le format du message de renice dépend de la version. La seconde consultation permet de vérifier la valeur réellement obtenue ; l'identité du PID doit toujours correspondre à votre cible. Si le processus s'est terminé ou si le numéro a été réutilisé, ne poursuivez pas sur la base de l'ancien relevé.

Dans la plage Linux usuelle de -20 à 19, passer de 0 à 10 diminue la préférence CPU. Passer de 15 à 10 la relève : le signe positif du nombre final ne suffit donc pas à déterminer le sens du changement. Comparez toujours l'ancienne et la nouvelle valeur.

Vérifier sur un processus de démonstration

Dans un terminal Bash sur une machine Linux de pratique disposant de util-linux et procps-ng, lancez un enfant qui attend seulement :

sleep 10 &
demo_pid=$!
ps -p "$demo_pid" -o pid,user,ni,comm

Pour le cas courant où le NI observé vaut 0, modifiez uniquement cet enfant puis laissez-le finir :

renice 10 -p "$demo_pid"
ps -p "$demo_pid" -o pid,ni,comm
wait "$demo_pid"

Le contrôle attendu montre le même PID et la commande sleep avec NI = 10. Si la valeur initiale était différente, n'appliquez pas cet exemple sans comparer le sens de la modification et vos droits. Si sleep a déjà terminé, recréez un nouvel enfant au lieu de réutiliser un PID ancien.

Cette attente ne mesure pas un effet de performance : elle rend simplement le réglage observable sans calcul intensif. Elle ne crée aucun fichier et finit naturellement. Pour un processus durable, relevez la valeur avant l'intervention et prévoyez les droits nécessaires à sa restauration : un utilisateur ordinaire ne peut pas forcément revenir de 10 à 0 après avoir diminué sa priorité.

Limiter le périmètre et comprendre les permissions

Un utilisateur non privilégié peut normalement agir sur ses propres processus dans le sens d'une augmentation de niceness. Abaisser le nombre peut exiger un privilège ou une limite de ressources adaptée. Un refus ne signifie donc pas nécessairement que le PID est erroné.

Renice ne réduit ni la mémoire allouée ni le nombre de processus. Il ne fixe pas non plus un plafond de consommation CPU et ne contourne pas les autres règles d'ordonnancement ou de groupes de contrôle du système. Vérifiez le type de ressource qui limite réellement votre application avant de considérer cette modification comme une solution.

La page de manuel renice du projet util-linux explique les modes absolu et relatif, les sélections et les permissions. Comparez-la à la documentation de la version installée pour les options disponibles.