reniceを使用してプロセスのNice値を増やすことができないのはなぜですか？
man reniceから：
スーパーユーザー以外のユーザーは、自分が所有するプロセスの優先度のみを変更できます「Nice値」を単調に増やすことができます（セキュリティ上の理由から） 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
どうしてこれなの？通常のユーザーがNice値を0未満に設定できない理由は理解できますが、優先度を10に下げることができるので、優先度を9に再度上げることができないのはなぜですか？これにはどのような「セキュリティ上の理由」がありますか？ Nice値が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年からだと思います。これは非常に簡単に修正できるはずです。そのため、一方で残すことを選択したように思われ、他方ではバグとしてリストされます。
Linux 2.6.12以降、それはRLIMIT_Nice制限（ulimit -e）の値に依存します。これは0から40までの値を取ることができます。その制限は、プロセスの優先度に対する制限です（その数値が大きいほど、優先度は高くなります）。ユーザーはプロセスに設定できます）。
たとえば、ubuntu 10.04ではデフォルト値は20、Debian jessieでは0です。
その制限の値がnの場合、CAP_Nice機能のないプロセスは、プロセスの優先順位を最大nは、nicenessを20 - nのnicenessに減らします。したがって、値が0の場合、非特権ユーザーはnicenessを20未満に下げることができないため、非特権ユーザーはnicenessを下げることができません。
値が20の場合、非特権ユーザーはnicenessを0に戻すことができます。
ユーザーがプロセスの優先度を下げることを許可するかどうか、およびハード制限を設定してどのレベルまで下げるかを選択するのは管理者の責任です。
管理者がユーザーにプロセスの優先度を下げたくない理由については、 Flupの回答 を参照してください。
それは私が呼ぶものですポリシー上の理由。この考え方は、通常のユーザーは特権ユーザーのアクションをオーバーライドできないということです。
あなたが巨大な共有サーバーのユーザーだとしましょう。あなたは他のユーザーに不利益をもたらす巨大なCPUを消費するプロセスを実行しています。 sysadmin renices彼はあなたをあまり好きではないので、あなたのプロセスのいくつか。 OSは、誰がreniceを実行したかを覚えていませんが、通常のユーザーがアクションを元に戻すことはできないことを認識しています。このようにして、sysadminは通常のユーザーのプロセスの優先順位を制御できます。