Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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:

     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.

share|improve this question
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 '14 at 10:29
up vote 15 down vote accepted

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.

share|improve this answer
Ah! So it is configurable! OK, that makes more sense, thanks. – terdon Mar 12 '14 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 at 10:19

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.

share|improve this answer
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 '14 at 10:36
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 '14 at 10:37
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 '14 at 10:43
@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 '14 at 5:22
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 '14 at 20:10

Strange ? it works for me on

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"
 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"
 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"
 4190   0
 8594   0
14684   0
21122  10
21146   0
21155   0
21213   0

2nd edit

$ cat /etc/lsb-release 

Config changes


@audio          -       rtprio          100
@audio          -       nice            -10

And I am member of audio group, this was to reduce latency with jack/ardour and buffer xruns when recording.


$ renice --version
renice from util-linux-ng 2.17.2
share|improve this answer
What distro are you on ? it doesn't on AIX 6.2 – Kiwy Mar 12 '14 at 10:47
Please post the output of cat /etc/lsb* and renice --version as well. – terdon Mar 12 '14 at 11:10
renice --version renice from util-linux-ng 2.17.2 but still on AIX it's not possible – Kiwy Mar 12 '14 at 11:37

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.