Comando renice in Linux: modificare il valore nice di un processo

renice cambia il valore nice di un processo già in esecuzione, influenzandone la priorità relativa della CPU. Prima di usarlo, verifica PID, proprietario e comando: un valore nice maggiore rende normalmente l’attività meno favorita nella contesa per la CPU.

La differenza rispetto a nice è il momento dell’intervento: nice avvia un nuovo comando, mentre renice agisce su attività esistenti. Renice non termina il processo, non ne riduce automaticamente la memoria e non impone un limite percentuale alla CPU.

Sintassi e significato del valore

renice -n priorita -p PID...

Gli esempi usano renice di util-linux con POSIXLY_CORRECT non impostata. In queste condizioni -n 10 indica il valore nice finale 10. Se invece questa variabile d’ambiente è impostata, il manuale corrente di util-linux definisce -n come una variazione relativa. Non confondere quindi sempre questo numero con l’incremento di GNU nice.

Consulta renice --version, renice --help e man renice nella versione installata. Puoi controllare la presenza della variabile con printenv POSIXLY_CORRECT; anche una variabile definita con valore vuoto può contare come impostata. Nelle versioni che le offrono, --priority e --relative esprimono esplicitamente valore assoluto e variazione. Verifica il supporto prima di usarle.

Esempi pratici

Controllare il valore corrente

Su Linux con ps di procps-ng, sostituisci 1234 con il PID di un tuo processo di prova ancora attivo. Controlla proprietario, comando e colonna NI, che mostra il valore nice. Non applicare l’esempio al PID letterale senza aver identificato l’attività.

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

Regolare il processo già avviato

Con util-linux e la condizione d’ambiente indicata sopra, questo comando imposta 10 come valore finale. Se il processo parte da 0, ne riduce la priorità relativa. Se parte già da 15, passare a 10 significa invece aumentarla e può richiedere autorizzazioni aggiuntive.

renice -n 10 -p 1234

Verificare il risultato

Leggi eventuali errori e interroga di nuovo lo stesso processo. Non dedurre il valore finale dalla sola intenzione espressa nel comando.

ps -p 1234 -o pid,ni,cmd

Confrontare prima e dopo

Per una prova semplice puoi avviare sleep 60 & in Bash e annotare subito il suo PID, disponibile in $!. Sostituisci il segnaposto PID nelle tre righe seguenti con quel numero. Esegui prima la consultazione, controlla il bersaglio e solo allora procedi alla modifica.

ps -o pid,ni,comm -p PID
renice -n 10 -p PID
ps -o pid,ni,comm -p PID

Se il valore iniziale era 0, la selezione è corretta, l’operazione riesce e -n è interpretato come assoluto, nell’ultima consultazione la colonna NI deve riportare 10 anziché 0. Il formato del messaggio di renice varia con l’implementazione. La sequenza non controlla automaticamente gli errori: non incollare le tre righe come sostituto della verifica del processo.

Sleep serve a lasciare tempo per osservare il valore, non a misurare prestazioni: normalmente attende senza creare una contesa significativa della CPU. Puoi lasciare terminare la prova. Un processo già concluso non può essere regolato, e il sistema può riutilizzarne il PID per un’altra attività.

Annota il valore iniziale per capire cosa è cambiato, ma non presumere di poterlo ripristinare senza permessi. Se aumenti il valore nice da 0 a 10, tornare a 0 aumenta la priorità e può non essere consentito a un utente ordinario. Per questo è preferibile esercitarsi con un processo temporaneo proprio.

Opzioni e ambito dei bersagli

Un gruppo di processi è un insieme identificato da un PGID, non il gruppo di utenti indicato da un GID. Le opzioni -u e -g possono coinvolgere molte attività: per una prova usa un singolo PID verificato. Una selezione più ampia non conferisce comunque i permessi necessari alla modifica.

Permessi e limiti su Linux

Un utente non privilegiato può normalmente modificare i propri processi soltanto aumentando il valore nice. Ridurlo richiede privilegi adeguati o un limite RLIMIT_NICE che lo consenta. Il manuale getpriority/setpriority descrive anche il ruolo di CAP_SYS_NICE e delle verifiche di proprietà. L’intervallo normalmente disponibile è da -20 a 19, con i valori minori più favorevoli alla CPU.

Ricontrollare il processo subito prima dell’azione riduce gli errori, ma una consultazione separata non blocca l’identità del PID. Dopo la modifica verifica ancora comando e valore. Su Linux il valore nice è un attributo del thread: non dare per scontato che un singolo PID regoli automaticamente tutti i thread di un programma complesso.

Una modifica riuscita non garantisce una determinata velocità né risolve attese di disco o memoria. Gruppi di attività, cgroup e altre politiche di pianificazione possono influire sulla quota effettiva di CPU. Individua il tipo di risorsa che costituisce il collo di bottiglia prima di scegliere una regolazione.

Nell’ambiente Windows con Git Bash disponibile per la verifica, renice non è installato e il ps locale non offre le stesse opzioni di procps-ng. Le quattro sequenze sono state controllate soltanto per la sintassi Bash: non è stata eseguita una modifica di priorità né verificata la colonna NI su Linux.

Domande frequenti

Qual è la differenza tra nice e renice?

Nice regola un nuovo comando al momento dell’avvio; renice modifica il valore di attività già avviate. Controlla inoltre il significato del numero: GNU nice usa un incremento, mentre util-linux renice usa normalmente un valore assoluto, con le condizioni d’ambiente e le opzioni illustrate sopra.

Documentazione di riferimento

Il manuale renice(1) del progetto util-linux documenta opzioni, selezione dei bersagli e differenze legate a POSIXLY_CORRECT. Confrontalo con il manuale della versione installata prima di applicare gli esempi.