Take the 2-minute tour ×
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.

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.

share|improve this question
    
no regular user can improve priority as far as I know –  Kiwy Mar 12 at 10:13
    
@Kiwy I know, that's what the question says. I am asking why. –  terdon Mar 12 at 10:14
    
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 at 10:29

3 Answers 3

up vote 14 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
1  
Ah! So it is configurable! OK, that makes more sense, thanks. –  terdon Mar 12 at 11:55

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
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 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 at 10:37
    
Yeah, but that's exactly my question, why? I should be allowed to play with the niceness of my processes within the range I have access to (0-20). –  terdon Mar 12 at 10:40
3  
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 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 at 5:22

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

example

$ 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

2nd edit

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

Config changes

/etc/security/limits.conf

@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

$ 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 at 10:47
    
Please post the output of cat /etc/lsb* and renice --version as well. –  terdon Mar 12 at 11:10
    
renice --version renice from util-linux-ng 2.17.2 but still on AIX it's not possible –  Kiwy Mar 12 at 11:37

Your Answer

 
discard

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.