Почему я не могу использовать renice, чтобы увеличить приятное значение процесса?

От man renice:

Пользователи, отличные от суперпользователя, могут изменять только приоритет процессов, которыми они владеют, и могут монотонно увеличивать свое «хорошее значение» (по соображениям безопасности) в диапазоне от 0 до PRIO_MAX (20) [...]

Итак, я могу использовать reniceсвои собственные процессы вверх (отдавая им более низкий приоритет), но никогда не снижая их:

$ 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

Почему это? Я могу понять, почему обычные пользователи не могут установить хорошие значения ниже 0, но почему, поскольку я могу уменьшить приоритет до 10, я не могу увеличить его снова до 9? Какая «причина безопасности» существует для этого? У меня есть право запустить процесс с хорошим значением 9, так почему я не могу изменить его до 9?

РЕДАКТИРОВАТЬ: я должен научиться прокручивать вниз. Оказывается, это указано как ошибка в 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.

Это еще более запутанно. Если они считают это поведение ошибкой, почему бы не изменить его? Команда reniceпоявилась в 4.0BSD, которая, я думаю, относится к 1980 году. Это должно быть очень легко исправить, так что, с одной стороны, они решили оставить ее, а с другой - перечислить ее как ошибку.

nice priority

— Тердон
источник

Поскольку некоторые приоритеты, превышающие 0, могут применяться системным процессом или модулем безопасности и никогда не должны уменьшаться пользователем (и нет достаточно точного управления, чтобы определить минимальную точность данного пользовательского процесса, отличную от фиксированного значения 0) ? Не ответ, как я не уверен, но предположение.

— lgeorget

Тот же вопрос на аскубунту .

— user202729

Ответы:

Начиная с Linux 2.6.12, это зависит от значения лимита RLIMIT_NICE ( ulimit -e). Может принимать значения от 0 до 40. Это ограничение больше ограничения приоритета процесса (чем больше это число, тем выше приоритет, который пользователь может установить для процесса).

Вы заметите, что значение по умолчанию равно 20 в Ubuntu 10.04 и 0 в Debian jessie, например.

Значение nэтого предела означает, что процесс без возможности CAP_NICE может только повысить приоритет процесса до значения n, что означает уменьшение степени полезности до уровня точности 20 - n. Таким образом, для значения 0 это означает, что ни один непривилегированный пользователь не может снизить милость ниже 20, поэтому ни один непривилегированный пользователь не может снизить милость.

При значении 20 непривилегированные пользователи могут уменьшить значение обратно до 0.

Администратор сам решает, разрешать ли пользователям снижать приоритет процесса и до какого уровня, устанавливая для этого жесткое ограничение.

Относительно того, почему администратор может не захотеть, чтобы пользователи понизили свой приоритет процесса, см . Ответ Flup .

— Стефан Шазелас
источник

Ах! Так что это настраивается! Хорошо, это имеет больше смысла, спасибо.

— Terdon

msgstr "значения от 0 до 40. [...] Вы заметите, что значение по умолчанию равно 20 в ubuntu 10.04 и 0 в Debian jessie, например." -> Интересно, жесткие / мягкие ограничения для меня действительно равны 0 на Debian Jessie. Я могу повысить до 20, но после этого я получаю «bash: ulimit: приоритет планирования: не могу изменить предел: неверный аргумент», отрицательные значения также не принимаются.

— Томанский

Это по причинам, которые я бы назвал политическими . Идея состоит в том, что обычные пользователи не могут переопределить действия привилегированных пользователей.

Допустим, вы пользователь на каком-то огромном общем сервере. Вы запускаете чудовищные процессы загрузки процессора в ущерб другим пользователям. Сисадмин - это кто- reniceто из ваших процессов, потому что он вам не очень нравится. ОС не помнит, кто это сделал renice, но она знает, что обычные пользователи не могут отменить действие. Таким образом, системный администратор может контролировать приоритеты процессов обычных пользователей.

— Flup
источник

Я могу это понять, но это все еще кажется странным. На самом деле, я только что понял, что это даже указано как ошибка в man renice.

— Terdon

Я думаю, что суть ошибки заключается в том, что «пользователи, не являющиеся суперпользователями, не могут увеличить приоритеты планирования своих собственных процессов, даже если они были теми, которые в первую очередь уменьшили приоритеты ». то есть побочным эффектом этого принуждения является то, что случайное reniceне может быть отменено, кроме как привилегированным пользователем.

— Flup

Потому что система не помнит, кто установил приоритет. В идеале, если вы подняли хороший уровень, а затем захотели понизить его, это было бы разрешено ... но система накладывает общий запрет именно потому, что она не ведет учет того, кто что сделал, так что вы не можете отменить reniceчто rootсделал.

— Flup

@IwillnotexistIdonotexist думать о системах со многими пользователями. Системный администратор, возможно, захочет повысить приоритет ваших процессов до 5, а моих - до 10. Это по-прежнему в пределах диапазона нормальных пользователей, но я не смогу изменить его и украсть то время процессора, которого вы заслуживаете. В любом случае это идея, как объяснил Flup. Однако, как объяснил StephaneChazelas , это настраивается, поэтому системный администратор должен выбрать, что он предпочитает.

— Тердон

Ответ «почему?» Скорее всего будет «потому что никому не нужно было достаточно для написания кода для его исправления». Когда Unix был изначально написан, отслеживание того, кто установил приоритет процесса, могло быть дорогостоящим с точки зрения использование памяти и работа по ее обновлению, но на современных машинах это ничтожно мало, просто не хватает мотивации для написания кода для отслеживания этого для сайтов, которые хотят сохранить первоначальную политику «пользователь не может переопределить sysadmin».

— alanc

-1

Странный ? это работает для меня на

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

пример

$ 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

2-е редактирование

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

Изменения конфигурации

/etc/security/limits.conf

@audio          -       rtprio          100
@audio          -       nice            -10

И я являюсь членом аудиогруппы, это должно было уменьшить задержку с помощью jack / ardour и буфера xruns при записи.

Renice

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

— X Тянь
источник

На каком дистрибутиве вы находитесь? это не в AIX 6.2

— Kiwy

Пожалуйста, опубликуйте результаты cat /etc/lsb*и renice --version.

— Terdon

renice --version renice from util-linux-ng 2.17.2но все же в AIX это невозможно

— Kiwy