¿Por qué no puedo usar renice para aumentar el buen valor de un proceso?

De man renice:

Los usuarios que no sean el superusuario solo pueden alterar la prioridad de los procesos que poseen, y solo pueden aumentar monotónicamente su `` buen valor '' (por razones de seguridad) dentro del rango de 0 a PRIO_MAX (20) [...]

Entonces, puedo renicemis propios procesos hacia arriba (darles una prioridad más baja) pero nunca hacia abajo:

$ 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

¿Por qué es esto? Puedo entender por qué los usuarios normales no pueden establecer valores agradables inferiores a 0, pero ¿por qué si puedo disminuir la prioridad a 10 no puedo aumentarlo nuevamente a 9? ¿Qué "razón de seguridad" hay para esto? Tengo derecho a iniciar un proceso con un buen valor de 9, entonces, ¿por qué no puedo cambiarlo a 9?

EDITAR: debería aprender a desplazarme hacia abajo. Resulta que esto aparece como un error en 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.

Eso es aún más confuso. Si consideran que este comportamiento es un error, ¿por qué no cambiarlo? El renicecomando apareció en 4.0BSD, que creo que es de 1980. Esto debería ser muy fácil de solucionar, por un lado, parecen haber optado por dejarlo y, por otro, lo enumeran como un error.

nice priority

— terdon
fuente

Debido a que un proceso del sistema o un módulo de seguridad puede imponer algunas prioridades superiores a 0 y nunca debe ser disminuido por el usuario (y no existe un control lo suficientemente fino como para definir la simplicidad mínima de un proceso de usuario dado que no sea el valor fijo 0) ? No es una respuesta ya que no estoy seguro, sino una suposición.

— lgeorget

La misma pregunta en askubuntu .

— user202729

Respuestas:

Desde linux 2.6.12, eso depende del valor del límite RLIMIT_NICE ( ulimit -e). Que puede tomar valores de 0 a 40. Ese límite es más el límite de la prioridad del proceso (cuanto mayor es ese número, mayor es la prioridad que un usuario puede establecer para un proceso).

Notará que el valor predeterminado es 20 en ubuntu 10.04 y 0 en Debian jessie, por ejemplo.

Un valor de nese límite significa que un proceso sin la capacidad CAP_NICE solo puede aumentar la prioridad de un proceso hasta n, lo que significa disminuir la simplicidad a una simplicidad de 20 - n. Entonces, para un valor de 0, eso significa que ningún usuario no privilegiado puede reducir la simpatía por debajo de 20, por lo que ningún usuario no privilegiado puede disminuir la simpatía.

Con un valor de 20, los usuarios sin privilegios pueden disminuir la simpatía a 0.

Depende del administrador elegir si permiten a los usuarios reducir la prioridad de su proceso y a qué nivel estableciendo el límite estricto para eso.

En cuanto a por qué un administrador puede no querer que los usuarios reduzcan la prioridad de su proceso, consulte la respuesta de Flup .

— Stéphane Chazelas
fuente

Ah! ¡Entonces es configurable! OK, eso tiene más sentido, gracias.

— terdon

"valores de 0 a 40. [...] Notará que el valor predeterminado es 20 en ubuntu 10.04 y 0 en Debian jessie, por ejemplo". -> Interesante, los límites duros / blandos para mí son de hecho 0 en Debian Jessie. Puedo subir hasta 20 pero más allá de eso obtengo "bash: ulimit: prioridad de programación: no se puede modificar el límite: argumento inválido", tampoco se aceptan valores negativos.

— thomanski

Es por lo que yo llamaría razones de política . La idea es que los usuarios normales no pueden anular las acciones de los usuarios privilegiados.

Digamos que eres un usuario en un enorme servidor compartido. Está ejecutando procesos monstruosos de acaparamiento de CPU en detrimento de los demás usuarios. El administrador de sistemas renicees uno de sus procesos porque no le quiere mucho. El sistema operativo no recuerda quién hizo el renice, pero sí sabe que los usuarios normales no pueden revertir la acción. De esta manera, el administrador del sistema tiene control sobre las prioridades de proceso de los usuarios normales.

— Flup
fuente

Puedo entender eso, pero aún parece extraño. De hecho, me di cuenta de que incluso aparece como un error en man renice.

— terdon

Creo que el punto del error es que 'Los no superusuarios no pueden aumentar las prioridades de programación de sus propios procesos, incluso si fueron ellos quienes disminuyeron las prioridades en primer lugar '. es decir, es un efecto secundario de esta aplicación que un accidente reniceno puede revertirse excepto por un usuario privilegiado.

— Flup

Porque el sistema no recuerda quién estableció la prioridad. Idealmente, si elevaras el nivel agradable y luego quisieras bajarlo, eso estaría permitido ... pero el sistema impone una prohibición general precisamente porque no mantiene registros de quién notó qué, para que no puedas deshacer un reniceEso roothizo.

— Flup

@IwillnotexistIdonotexist piensa en sistemas con muchos usuarios. El administrador del sistema puede querer aumentar la prioridad de sus procesos a 5 y reducir los míos a 10. Eso todavía está dentro del rango de los usuarios normales, pero no podré cambiarlo y robarle el tiempo de CPU que merece. Esa es la idea de todos modos, como explicó Flup. Sin embargo, como explicó StephaneChazelas , esto es configurable, por lo que depende del administrador del sistema elegir lo que prefiera.

— terdon

La respuesta a "¿por qué?" Es más probable que sea "porque nadie lo necesitaba lo suficiente como para escribir el código para solucionarlo". Cuando se escribió originalmente Unix, el seguimiento de quién estableció la prioridad de un proceso podría haber sido costoso en términos de uso de la memoria y el trabajo para actualizarlo, pero en las máquinas modernas, eso es insignificante, acaba de salir de la falta de motivación para escribir el código para realizar un seguimiento de este para los sitios que quieren mantener la política original de “usuario no puede anular administrador de sistemas.”

— alanc

-1

Extraño? me funciona en

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

ejemplo

$ 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

2da edición

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

Cambios de configuración

/etc/security/limits.conf

@audio          -       rtprio          100
@audio          -       nice            -10

Y soy miembro del grupo de audio, esto fue para reducir la latencia con jack / ardor y buffer xruns durante la grabación.

re bueno

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

— X Tian
fuente

¿En qué distribución estás? no lo hace en AIX 6.2

— Kiwy

Por favor, publique la salida de cat /etc/lsb*y renice --versiontambién.

— terdon

renice --version renice from util-linux-ng 2.17.2pero todavía en AIX no es posible

— Kiwy