30

From man renice:

Users other than the super-user may only alter the priority of processes they own, and can only monotonically increase their ``nice value'' (for security reasons) within the range 0 to PRIO_MAX (20) [...]

So, I can renice my own processes upwards (give them lower priority) but never downwards:

$ 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

Why is this? I can understand why normal users cannot set nice values lower than 0, but why since I can decrease the priority to 10 can't I increase it again to 9? What "security reason" is there for this? I have the right to launch a process with a nice value of 9, so why can't I renice it to 9?

EDIT: I should learn to scroll down. Turns out this is listed as a 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.

That's even more confusing. If they consider this behavior to be a bug, why not change it? The renice command appeared in 4.0BSD which I think is from 1980. This should be very easy to fix so on the one hand they seem to have chosen to leave it and on the other they list it as a bug.

2
  • Because some priorities higher than 0 may be enforced by a system process or a security module and should never be decreased by the user (and there is no control fine enough to define the minimal niceness of a given user process other than the fixed value 0)? Not an answer as I'm not sure but a guess.
    – lgeorget
    Mar 12, 2014 at 10:29
  • Same question on askubuntu.
    – user202729
    Sep 8, 2018 at 5:53

2 Answers 2

Reset to default
24

Since linux 2.6.12, that depends on the value of the RLIMIT_NICE limit (ulimit -e). Which can take values from 0 to 40. That limit is more the limit on the priority of the process (the greater that number, the higher the priority a user can set for a process).

You'll notice the default value is 20 on ubuntu 10.04 and 0 in Debian jessie for instance.

A value of n for that limit means that a process without the CAP_NICE capability can only increase a process priority to up to n, which means decrease niceness down to a niceness of 20 - n. So for a value of 0, that means no non-privileged user can lower the niceness below 20, so no non-privileged user can lower the niceness.

With a value of 20, non-privileged users can decrease the niceness back to 0.

It's up to the administrator to choose whether they allow users to lower their process priority, and to what level by setting the hard limit for that.

As to why an administrator may not want users to lower their process priority, see Flup's answer.

4
  • 1
    Ah! So it is configurable! OK, that makes more sense, thanks.
    – terdon ♦
    Mar 12, 2014 at 11:55
  • "values from 0 to 40. [...] You'll notice the default value is 20 on ubuntu 10.04 and 0 in Debian jessie for instance." -> Interesting, hard/soft ulimits for me are indeed 0 on debian jessie. I can raise up to 20 but beyond that I get "bash: ulimit: scheduling priority: cannot modify limit: Invalid argument", negative values aren't accepted either.
    – thomanski
    Jun 1, 2016 at 10:19
  • @terdon how do you change it? in need it to be 20 on my ubuntu or wine fails.
    – tatsu
    Jan 20, 2021 at 2:27
  • I don't like this answer either. Again, you can restart any process and circumvent this idiotic restriction. In short it least for me the question has not been answered.
    – Artem S. Tashkinov
    Dec 21, 2021 at 13:18
24

It's for what I'd call policy reasons. The idea is that normal users can't override the actions of privileged users.

Let's say you're a user on some enormous shared server. You're running monstrous CPU-hogging processes to the detriment of the other users. The sysadmin renices some of your processes because he doesn't like you very much. The OS doesn't remember who did the renice, but it does know that normal users can't reverse the action. In this way, the sysadmin has control over normal users' process priorities.

8
  • 1
    I can understand that but it still seems strange. In fact, I just realized that it's even listed as a bug in man renice.
    – terdon ♦
    Mar 12, 2014 at 10:36
  • 3
    I think the point of the bug is that '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'. i.e. it's a side-effect of this enforcement that an accidental renice can't be reversed except by a privileged user.
    – Flup
    Mar 12, 2014 at 10:37
  • 7
    Because the system doesn't remember who set the priority. Ideally, if you raised the nice level and then wanted to lower it, that would be permitted... but the system imposes a blanket prohibition precisely because it doesn't keep records of who niced what, so that you can't undo a renice that root did.
    – Flup
    Mar 12, 2014 at 10:43
  • 1
    @IwillnotexistIdonotexist think of systems with many users. The sysadmin may want to raise the priority of your processes to 5 and lower those of mine to 10. That's still within the range of normal users but I won't be able to change it and steal the CPU time you deserve. That's the idea anyway as Flup explained. However, as StephaneChazelas explained, this is configurable so it's up to the sysadmin to choose what they prefer.
    – terdon ♦
    Mar 13, 2014 at 5:22
  • 1
    The answer to “why?” is simply most likely to be “because no one needed it enough to write the code to fix it.” When Unix was originally written, tracking who set the priority of a process might have been expensive in terms of memory usage and work to update it, but on modern machines, that's negligible, just leaving lack of motivation for writing the code to track this for sites that want to keep the original policy of “user can't override sysadmin.”
    – alanc
    Mar 13, 2014 at 20:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .