Perché non posso usare Renice per aumentare il valore di un processo?

Da man renice:

Gli utenti diversi dal superutente possono solo modificare la priorità dei processi di loro proprietà e possono solo aumentare monotonicamente il loro `` buon valore '' (per motivi di sicurezza) nell'intervallo da 0 a PRIO_MAX (20) [...]

Quindi, posso i renicemiei processi verso l'alto (dare loro una priorità inferiore) ma mai verso il basso:

$ 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

Perchè è questo? Posso capire perché gli utenti normali non possono impostare valori piacevoli inferiori a 0, ma perché poiché posso ridurre la priorità a 10 non posso aumentarla di nuovo a 9? Quale "motivo di sicurezza" esiste per questo? Ho il diritto di avviare un processo con un buon valore di 9, quindi perché non riesco a ridimensionarlo a 9?

EDIT: dovrei imparare a scorrere verso il basso. Si scopre che questo è elencato come un bug in 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.

È ancora più confuso. Se considerano questo comportamento un bug, perché non modificarlo? Il renicecomando è apparso in 4.0BSD che penso sia del 1980. Questo dovrebbe essere molto facile da risolvere, quindi da un lato sembrano aver scelto di lasciarlo e dall'altro lo elencano come un bug.

nice priority

— terdon
fonte

Perché alcune priorità superiori a 0 possono essere applicate da un processo di sistema o da un modulo di sicurezza e non devono mai essere ridotte dall'utente (e non esiste un controllo sufficientemente preciso per definire la minima precisione di un determinato processo utente diverso dal valore fisso 0) ? Non una risposta perché non ne sono sicuro ma un'ipotesi.

— Lgeorget,

Stessa domanda su askubuntu .

— user202729

Risposte:

A partire da Linux 2.6.12, ciò dipende dal valore del limite RLIMIT_NICE ( ulimit -e). Che può assumere valori da 0 a 40. Quel limite è più il limite sulla priorità del processo (maggiore è quel numero, maggiore è la priorità che un utente può impostare per un processo).

Noterai che il valore predefinito è 20 su Ubuntu 10.04 e 0 in Debian jessie per esempio.

Un valore di nper quel limite significa che un processo senza la capacità CAP_NICE può solo aumentare una priorità del processo fino a n, il che significa ridurre la gentilezza fino a una gentilezza di 20 - n. Quindi per un valore pari a 0, ciò significa che nessun utente non privilegiato può abbassare la gentilezza al di sotto di 20, quindi nessun utente non privilegiato può abbassare la gentilezza.

Con un valore di 20, gli utenti non privilegiati possono ridurre la gentilezza a 0.

Spetta all'amministratore scegliere se consentire agli utenti di ridurre la priorità del processo e a quale livello impostando il limite rigido per questo.

Per sapere perché un amministratore potrebbe non volere che gli utenti riducano la priorità del processo, vedere la risposta di Flup .

— Stéphane Chazelas
fonte

Ah! Quindi è configurabile! OK, ha più senso, grazie.

— terdon

"valori da 0 a 40. [...] Noterai che il valore predefinito è 20 su Ubuntu 10.04 e 0 in Debian jessie per esempio." -> Interessanti, hard / soft ulimits per me sono davvero 0 su Debian Jessie. Posso alzare fino a 20 ma oltre a ciò ottengo "bash: ulimit: priorità di pianificazione: impossibile modificare il limite: argomento non valido", neanche i valori negativi sono accettati.

— Thomanski,

È per quello che definirei motivi politici . L'idea è che gli utenti normali non possono ignorare le azioni degli utenti privilegiati.

Diciamo che sei un utente su un enorme server condiviso. Stai eseguendo mostruosi processi di hogging della CPU a danno degli altri utenti. Il amministratore renicedi sistema gestisce alcuni dei tuoi processi perché non gli piaci molto. Il sistema operativo non ricorda chi ha eseguito l'operazione renice, ma sa che gli utenti normali non possono annullare l'azione. In questo modo, l'amministratore di sistema ha il controllo sulle normali priorità di processo degli utenti.

— flup
fonte

Posso capirlo, ma sembra ancora strano. In effetti, ho appena realizzato che è persino elencato come un bug in man renice.

— terdon

Penso che il punto del bug sia che "i non superutenti non possono aumentare le priorità di pianificazione dei propri processi, anche se sono stati quelli che hanno diminuito le priorità in primo luogo ". cioè è un effetto collaterale di questa applicazione che un accidentale renicenon può essere annullato se non da un utente privilegiato.

— Flup,

Perché il sistema non ricorda chi ha impostato la priorità. Idealmente, se hai alzato il buon livello e poi hai voluto abbassarlo, questo sarebbe permesso ... ma il sistema impone un divieto generale proprio perché non tiene traccia di chi ha dato fastidio a ciò, in modo da non poter annullare un renicequello ha rootfatto.

— Flup,

@IwillnotexistIdonotexist pensa ai sistemi con molti utenti. Il sysadmin potrebbe voler aumentare la priorità dei tuoi processi a 5 e abbassare quelli miei su 10. Questo è ancora nell'intervallo degli utenti normali, ma non sarò in grado di cambiarlo e rubare il tempo della CPU che meriti. Questa è comunque l'idea, come ha spiegato Flup. Tuttavia, come ha spiegato StephaneChazelas , questo è configurabile, quindi spetta al amministratore di sistema scegliere ciò che preferisce.

— terdon

È molto probabile che la risposta a "perché?" Sia "perché nessuno ne aveva abbastanza bisogno per scrivere il codice per risolverlo". Quando Unix era stato originariamente scritto, tenere traccia di chi stabiliva la priorità di un processo avrebbe potuto essere costoso in termini di utilizzo della memoria e lavoro per aggiornarlo, ma su macchine moderne, è trascurabile, lasciando solo la mancanza di motivazione per scrivere il codice per rintracciarlo per i siti che vogliono mantenere la politica originale di "l'utente non può ignorare sysadmin".

— alanc

-1

Strano? funziona per me

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

esempio

$ 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

2a modifica

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

Config cambia

/etc/security/limits.conf

@audio          -       rtprio          100
@audio          -       nice            -10

E sono membro del gruppo audio, questo per ridurre la latenza con jack / ardor e buffer xruns durante la registrazione.

renice

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

— X Tian
fonte

In quale distro sei? non su AIX 6.2

— Kiwy

Si prega di pubblicare l'output di cat /etc/lsb*e renice --versionpure.

— terdon

renice --version renice from util-linux-ng 2.17.2ma ancora su AIX non è possibile

— Kiwy