Set default nice value for a given user (limits.conf)
up vote
11
down vote
favorite
Could someone tell me how to set the default value of nice (as displayed by top) of a user? I have found that /etc/security/limits.conf is the place but if I put either:
username_of_a_guy - nice 19
username_of_a_guy soft nice 19
username_of_a_guy hard nice 19
It doesn't work (while it should, right?).
Note that I've rebooted since then.
Thank you very much in advance for any help. I'm using debian unstable (uptodate).
Context:
At my work, we have a local network: everyone has its own computer and everyone can create an account on someone else's machine if one likes. The rule of thumb is simply that if you work on someone else computer, please nice your processes (nice 19).
I would like to set the default nice value for a given user to 19 once and for all.
login nice limit
asked Mar 10 '11 at 12:02
Alex
58118
add a comment |
up vote
11
down vote
favorite
Could someone tell me how to set the default value of nice (as displayed by top) of a user? I have found that /etc/security/limits.conf is the place but if I put either:
username_of_a_guy - nice 19
username_of_a_guy soft nice 19
username_of_a_guy hard nice 19
It doesn't work (while it should, right?).
Note that I've rebooted since then.
Thank you very much in advance for any help. I'm using debian unstable (uptodate).
Context:
At my work, we have a local network: everyone has its own computer and everyone can create an account on someone else's machine if one likes. The rule of thumb is simply that if you work on someone else computer, please nice your processes (nice 19).
I would like to set the default nice value for a given user to 19 once and for all.
login nice limit
asked Mar 10 '11 at 12:02
Alex
58118
Somewhat related: unix.stackexchange.com/questions/209398/…
– Kusalananda
Apr 14 at 16:23
add a comment |
up vote
11
down vote
favorite
up vote
11
down vote
favorite
Could someone tell me how to set the default value of nice (as displayed by top) of a user? I have found that /etc/security/limits.conf is the place but if I put either:
username_of_a_guy - nice 19
username_of_a_guy soft nice 19
username_of_a_guy hard nice 19
It doesn't work (while it should, right?).
Note that I've rebooted since then.
Thank you very much in advance for any help. I'm using debian unstable (uptodate).
Context:
At my work, we have a local network: everyone has its own computer and everyone can create an account on someone else's machine if one likes. The rule of thumb is simply that if you work on someone else computer, please nice your processes (nice 19).
I would like to set the default nice value for a given user to 19 once and for all.
login nice limit
asked Mar 10 '11 at 12:02
Alex
58118
Could someone tell me how to set the default value of nice (as displayed by top) of a user? I have found that /etc/security/limits.conf is the place but if I put either:
username_of_a_guy - nice 19
username_of_a_guy soft nice 19
username_of_a_guy hard nice 19
It doesn't work (while it should, right?).
Note that I've rebooted since then.
Thank you very much in advance for any help. I'm using debian unstable (uptodate).
Context:
At my work, we have a local network: everyone has its own computer and everyone can create an account on someone else's machine if one likes. The rule of thumb is simply that if you work on someone else computer, please nice your processes (nice 19).
I would like to set the default nice value for a given user to 19 once and for all.
login nice limit
login nice limit
asked Mar 10 '11 at 12:02
Alex
58118
asked Mar 10 '11 at 12:02
Alex
58118
edited Dec 5 at 19:22
asked Mar 10 '11 at 12:02
Alex
58118
asked Mar 10 '11 at 12:02
Alex
58118
asked Mar 10 '11 at 12:02
Alex
58118
58118
Somewhat related: unix.stackexchange.com/questions/209398/…
– Kusalananda
Apr 14 at 16:23
add a comment |
Somewhat related: unix.stackexchange.com/questions/209398/…
– Kusalananda
Apr 14 at 16:23
Somewhat related: unix.stackexchange.com/questions/209398/…
– Kusalananda
Apr 14 at 16:23
Somewhat related: unix.stackexchange.com/questions/209398/…
– Kusalananda
Apr 14 at 16:23
add a comment |
2 Answers
2
active
oldest
votes
up vote
12
down vote
accepted
I believe the correct format is:
@users - priority 10
username - priority 19
This is an example of the settings I am using in production (obviously with real users/groups).
The nice setting is to determine the minimum nice value (i.e. maximum priority) someone can set their process to, not their default priority.
edited Jul 28 '17 at 21:46
Dr Beco
436314
answered Mar 10 '11 at 13:32
jsbillings
16k34148
2
First of all, thanks for your answer ( thank you as well, @mattdm ). It seems this method works. However, I'm still confused about the difference between "nice" and "priority" : both are displayed by "top" but the value quoted for nice is the one I have to set for priority. It looks a bit strange to me. Also, does a bigger priority (say 39 instead of 20) mean a less important process as it does for nice? Thank you.
– Alex
Mar 10 '11 at 14:10
4
The 'NI' nice priority in top is what would be set by the limitsprioritysetting. This will be the default priority of any processes for that user/group when they log in. You can only set this to be between -20 and 20. The 'PR' value in top is the actual scheduler priority, which is determined by several factors by the kernel's scheduler.
– jsbillings
Mar 10 '11 at 14:26
1
Also, yes, a higher priority means that it is less likely to be scheduled to get CPU cycles.
– jsbillings
Mar 10 '11 at 14:32
1
Ok, thanks a lot for this disambiguation. BTW, I haven't tried the other methods (involvingandorcgroup) which might be better in other situations than mine (need of a continuous check, or management of many users -which is a bit too much in my case).
– Alex
Mar 10 '11 at 16:05
Hmmmm... This worked for one user but not the other on my Ubuntu machine. I'll come back if I can work out why. ;-)
– Ken Sharp
Dec 18 '15 at 13:27
add a comment |
up vote
3
down vote
I can confirm that that doesn't work on my system either. The docs say "kernel 2.6.11 and up", and I'm on Fedora rawhide with kernel 2.6.38-rc6. I wonder if it is scheduler-dependent, and doesn't work with the introduced-in-2.6.23 CFQ ("Completely Fair Scheduler").
Something that will work, though, is the impossible-to-search-for-because-of-its-horrible-name and — the auto-nice daemon. See
http://and.sourceforge.net/. This is available from Fedora with yum install and, but unfortunately doesn't seem to be in EPEL. And it's in Debian too: apt-get install and.
If you are using a modern distribution, though, there's an Even Better Way. You can use the tools from libcgroup to set up a kernel-level cgroup limiting CPU shares, and to automatically "classify" that user's processes into this cgroup. With this, you can also prioritize I/O, and limit memory usage (including share of the disk cache).
answered Mar 10 '11 at 13:04
mattdm
27.8k1172111
I agree that using cgroups is an excellent way to limit other people from hogging all the CPU cycles on your computer. Sadly, the systems I support (RHEL5) don't have kernels that support it, so I have to stick with adjusting the priority. Once we update to RHEL6, I'm sure we'll have some fairly complex cgroups settings.
– jsbillings
Mar 10 '11 at 15:00
add a comment |
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
12
down vote
accepted
I believe the correct format is:
@users - priority 10
username - priority 19
This is an example of the settings I am using in production (obviously with real users/groups).
The nice setting is to determine the minimum nice value (i.e. maximum priority) someone can set their process to, not their default priority.
edited Jul 28 '17 at 21:46
Dr Beco
436314
answered Mar 10 '11 at 13:32
jsbillings
16k34148
2
First of all, thanks for your answer ( thank you as well, @mattdm ). It seems this method works. However, I'm still confused about the difference between "nice" and "priority" : both are displayed by "top" but the value quoted for nice is the one I have to set for priority. It looks a bit strange to me. Also, does a bigger priority (say 39 instead of 20) mean a less important process as it does for nice? Thank you.
– Alex
Mar 10 '11 at 14:10
4
The 'NI' nice priority in top is what would be set by the limitsprioritysetting. This will be the default priority of any processes for that user/group when they log in. You can only set this to be between -20 and 20. The 'PR' value in top is the actual scheduler priority, which is determined by several factors by the kernel's scheduler.
– jsbillings
Mar 10 '11 at 14:26
1
Also, yes, a higher priority means that it is less likely to be scheduled to get CPU cycles.
– jsbillings
Mar 10 '11 at 14:32
1
Ok, thanks a lot for this disambiguation. BTW, I haven't tried the other methods (involvingandorcgroup) which might be better in other situations than mine (need of a continuous check, or management of many users -which is a bit too much in my case).
– Alex
Mar 10 '11 at 16:05
Hmmmm... This worked for one user but not the other on my Ubuntu machine. I'll come back if I can work out why. ;-)
– Ken Sharp
Dec 18 '15 at 13:27
add a comment |
up vote
12
down vote
accepted
I believe the correct format is:
@users - priority 10
username - priority 19
This is an example of the settings I am using in production (obviously with real users/groups).
The nice setting is to determine the minimum nice value (i.e. maximum priority) someone can set their process to, not their default priority.
edited Jul 28 '17 at 21:46
Dr Beco
436314
answered Mar 10 '11 at 13:32
jsbillings
16k34148
2
First of all, thanks for your answer ( thank you as well, @mattdm ). It seems this method works. However, I'm still confused about the difference between "nice" and "priority" : both are displayed by "top" but the value quoted for nice is the one I have to set for priority. It looks a bit strange to me. Also, does a bigger priority (say 39 instead of 20) mean a less important process as it does for nice? Thank you.
– Alex
Mar 10 '11 at 14:10
4
The 'NI' nice priority in top is what would be set by the limitsprioritysetting. This will be the default priority of any processes for that user/group when they log in. You can only set this to be between -20 and 20. The 'PR' value in top is the actual scheduler priority, which is determined by several factors by the kernel's scheduler.
– jsbillings
Mar 10 '11 at 14:26
1
Also, yes, a higher priority means that it is less likely to be scheduled to get CPU cycles.
– jsbillings
Mar 10 '11 at 14:32
1
Ok, thanks a lot for this disambiguation. BTW, I haven't tried the other methods (involvingandorcgroup) which might be better in other situations than mine (need of a continuous check, or management of many users -which is a bit too much in my case).
– Alex
Mar 10 '11 at 16:05
Hmmmm... This worked for one user but not the other on my Ubuntu machine. I'll come back if I can work out why. ;-)
– Ken Sharp
Dec 18 '15 at 13:27
add a comment |
up vote
12
down vote
accepted
up vote
12
down vote
accepted
I believe the correct format is:
@users - priority 10
username - priority 19
This is an example of the settings I am using in production (obviously with real users/groups).
The nice setting is to determine the minimum nice value (i.e. maximum priority) someone can set their process to, not their default priority.
edited Jul 28 '17 at 21:46
Dr Beco
436314
answered Mar 10 '11 at 13:32
jsbillings
16k34148
I believe the correct format is:
@users - priority 10
username - priority 19
This is an example of the settings I am using in production (obviously with real users/groups).
The nice setting is to determine the minimum nice value (i.e. maximum priority) someone can set their process to, not their default priority.
edited Jul 28 '17 at 21:46
Dr Beco
436314
answered Mar 10 '11 at 13:32
jsbillings
16k34148
edited Jul 28 '17 at 21:46
Dr Beco
436314
edited Jul 28 '17 at 21:46
Dr Beco
436314
edited Jul 28 '17 at 21:46
Dr Beco
436314
436314
answered Mar 10 '11 at 13:32
jsbillings
16k34148
answered Mar 10 '11 at 13:32
jsbillings
16k34148
answered Mar 10 '11 at 13:32
jsbillings
16k34148
16k34148
2
First of all, thanks for your answer ( thank you as well, @mattdm ). It seems this method works. However, I'm still confused about the difference between "nice" and "priority" : both are displayed by "top" but the value quoted for nice is the one I have to set for priority. It looks a bit strange to me. Also, does a bigger priority (say 39 instead of 20) mean a less important process as it does for nice? Thank you.
– Alex
Mar 10 '11 at 14:10
4
The 'NI' nice priority in top is what would be set by the limitsprioritysetting. This will be the default priority of any processes for that user/group when they log in. You can only set this to be between -20 and 20. The 'PR' value in top is the actual scheduler priority, which is determined by several factors by the kernel's scheduler.
– jsbillings
Mar 10 '11 at 14:26
1
Also, yes, a higher priority means that it is less likely to be scheduled to get CPU cycles.
– jsbillings
Mar 10 '11 at 14:32
1
Ok, thanks a lot for this disambiguation. BTW, I haven't tried the other methods (involvingandorcgroup) which might be better in other situations than mine (need of a continuous check, or management of many users -which is a bit too much in my case).
– Alex
Mar 10 '11 at 16:05
Hmmmm... This worked for one user but not the other on my Ubuntu machine. I'll come back if I can work out why. ;-)
– Ken Sharp
Dec 18 '15 at 13:27
add a comment |
2
First of all, thanks for your answer ( thank you as well, @mattdm ). It seems this method works. However, I'm still confused about the difference between "nice" and "priority" : both are displayed by "top" but the value quoted for nice is the one I have to set for priority. It looks a bit strange to me. Also, does a bigger priority (say 39 instead of 20) mean a less important process as it does for nice? Thank you.
– Alex
Mar 10 '11 at 14:10
4
The 'NI' nice priority in top is what would be set by the limitsprioritysetting. This will be the default priority of any processes for that user/group when they log in. You can only set this to be between -20 and 20. The 'PR' value in top is the actual scheduler priority, which is determined by several factors by the kernel's scheduler.
– jsbillings
Mar 10 '11 at 14:26
1
Also, yes, a higher priority means that it is less likely to be scheduled to get CPU cycles.
– jsbillings
Mar 10 '11 at 14:32
1
Ok, thanks a lot for this disambiguation. BTW, I haven't tried the other methods (involvingandorcgroup) which might be better in other situations than mine (need of a continuous check, or management of many users -which is a bit too much in my case).
– Alex
Mar 10 '11 at 16:05
Hmmmm... This worked for one user but not the other on my Ubuntu machine. I'll come back if I can work out why. ;-)
– Ken Sharp
Dec 18 '15 at 13:27
2
2
First of all, thanks for your answer ( thank you as well, @mattdm ). It seems this method works. However, I'm still confused about the difference between "nice" and "priority" : both are displayed by "top" but the value quoted for nice is the one I have to set for priority. It looks a bit strange to me. Also, does a bigger priority (say 39 instead of 20) mean a less important process as it does for nice? Thank you.
– Alex
Mar 10 '11 at 14:10
First of all, thanks for your answer ( thank you as well, @mattdm ). It seems this method works. However, I'm still confused about the difference between "nice" and "priority" : both are displayed by "top" but the value quoted for nice is the one I have to set for priority. It looks a bit strange to me. Also, does a bigger priority (say 39 instead of 20) mean a less important process as it does for nice? Thank you.
– Alex
Mar 10 '11 at 14:10
4
4
The 'NI' nice priority in top is what would be set by the limits
priority setting. This will be the default priority of any processes for that user/group when they log in. You can only set this to be between -20 and 20. The 'PR' value in top is the actual scheduler priority, which is determined by several factors by the kernel's scheduler.– jsbillings
Mar 10 '11 at 14:26
The 'NI' nice priority in top is what would be set by the limits
priority setting. This will be the default priority of any processes for that user/group when they log in. You can only set this to be between -20 and 20. The 'PR' value in top is the actual scheduler priority, which is determined by several factors by the kernel's scheduler.– jsbillings
Mar 10 '11 at 14:26
1
1
Also, yes, a higher priority means that it is less likely to be scheduled to get CPU cycles.
– jsbillings
Mar 10 '11 at 14:32
Also, yes, a higher priority means that it is less likely to be scheduled to get CPU cycles.
– jsbillings
Mar 10 '11 at 14:32
1
1
Ok, thanks a lot for this disambiguation. BTW, I haven't tried the other methods (involving
and or cgroup) which might be better in other situations than mine (need of a continuous check, or management of many users -which is a bit too much in my case).– Alex
Mar 10 '11 at 16:05
Ok, thanks a lot for this disambiguation. BTW, I haven't tried the other methods (involving
and or cgroup) which might be better in other situations than mine (need of a continuous check, or management of many users -which is a bit too much in my case).– Alex
Mar 10 '11 at 16:05
Hmmmm... This worked for one user but not the other on my Ubuntu machine. I'll come back if I can work out why. ;-)
– Ken Sharp
Dec 18 '15 at 13:27
Hmmmm... This worked for one user but not the other on my Ubuntu machine. I'll come back if I can work out why. ;-)
– Ken Sharp
Dec 18 '15 at 13:27
add a comment |
up vote
3
down vote
I can confirm that that doesn't work on my system either. The docs say "kernel 2.6.11 and up", and I'm on Fedora rawhide with kernel 2.6.38-rc6. I wonder if it is scheduler-dependent, and doesn't work with the introduced-in-2.6.23 CFQ ("Completely Fair Scheduler").
Something that will work, though, is the impossible-to-search-for-because-of-its-horrible-name and — the auto-nice daemon. See
http://and.sourceforge.net/. This is available from Fedora with yum install and, but unfortunately doesn't seem to be in EPEL. And it's in Debian too: apt-get install and.
If you are using a modern distribution, though, there's an Even Better Way. You can use the tools from libcgroup to set up a kernel-level cgroup limiting CPU shares, and to automatically "classify" that user's processes into this cgroup. With this, you can also prioritize I/O, and limit memory usage (including share of the disk cache).
answered Mar 10 '11 at 13:04
mattdm
27.8k1172111
I agree that using cgroups is an excellent way to limit other people from hogging all the CPU cycles on your computer. Sadly, the systems I support (RHEL5) don't have kernels that support it, so I have to stick with adjusting the priority. Once we update to RHEL6, I'm sure we'll have some fairly complex cgroups settings.
– jsbillings
Mar 10 '11 at 15:00
add a comment |
up vote
3
down vote
I can confirm that that doesn't work on my system either. The docs say "kernel 2.6.11 and up", and I'm on Fedora rawhide with kernel 2.6.38-rc6. I wonder if it is scheduler-dependent, and doesn't work with the introduced-in-2.6.23 CFQ ("Completely Fair Scheduler").
Something that will work, though, is the impossible-to-search-for-because-of-its-horrible-name and — the auto-nice daemon. See
http://and.sourceforge.net/. This is available from Fedora with yum install and, but unfortunately doesn't seem to be in EPEL. And it's in Debian too: apt-get install and.
If you are using a modern distribution, though, there's an Even Better Way. You can use the tools from libcgroup to set up a kernel-level cgroup limiting CPU shares, and to automatically "classify" that user's processes into this cgroup. With this, you can also prioritize I/O, and limit memory usage (including share of the disk cache).
answered Mar 10 '11 at 13:04
mattdm
27.8k1172111
I agree that using cgroups is an excellent way to limit other people from hogging all the CPU cycles on your computer. Sadly, the systems I support (RHEL5) don't have kernels that support it, so I have to stick with adjusting the priority. Once we update to RHEL6, I'm sure we'll have some fairly complex cgroups settings.
– jsbillings
Mar 10 '11 at 15:00
add a comment |
up vote
3
down vote
up vote
3
down vote
I can confirm that that doesn't work on my system either. The docs say "kernel 2.6.11 and up", and I'm on Fedora rawhide with kernel 2.6.38-rc6. I wonder if it is scheduler-dependent, and doesn't work with the introduced-in-2.6.23 CFQ ("Completely Fair Scheduler").
Something that will work, though, is the impossible-to-search-for-because-of-its-horrible-name and — the auto-nice daemon. See
http://and.sourceforge.net/. This is available from Fedora with yum install and, but unfortunately doesn't seem to be in EPEL. And it's in Debian too: apt-get install and.
If you are using a modern distribution, though, there's an Even Better Way. You can use the tools from libcgroup to set up a kernel-level cgroup limiting CPU shares, and to automatically "classify" that user's processes into this cgroup. With this, you can also prioritize I/O, and limit memory usage (including share of the disk cache).
answered Mar 10 '11 at 13:04
mattdm
27.8k1172111
I can confirm that that doesn't work on my system either. The docs say "kernel 2.6.11 and up", and I'm on Fedora rawhide with kernel 2.6.38-rc6. I wonder if it is scheduler-dependent, and doesn't work with the introduced-in-2.6.23 CFQ ("Completely Fair Scheduler").
Something that will work, though, is the impossible-to-search-for-because-of-its-horrible-name and — the auto-nice daemon. See
http://and.sourceforge.net/. This is available from Fedora with yum install and, but unfortunately doesn't seem to be in EPEL. And it's in Debian too: apt-get install and.
If you are using a modern distribution, though, there's an Even Better Way. You can use the tools from libcgroup to set up a kernel-level cgroup limiting CPU shares, and to automatically "classify" that user's processes into this cgroup. With this, you can also prioritize I/O, and limit memory usage (including share of the disk cache).
answered Mar 10 '11 at 13:04
mattdm
27.8k1172111
answered Mar 10 '11 at 13:04
mattdm
27.8k1172111
answered Mar 10 '11 at 13:04
mattdm
27.8k1172111
answered Mar 10 '11 at 13:04
mattdm
27.8k1172111
27.8k1172111
I agree that using cgroups is an excellent way to limit other people from hogging all the CPU cycles on your computer. Sadly, the systems I support (RHEL5) don't have kernels that support it, so I have to stick with adjusting the priority. Once we update to RHEL6, I'm sure we'll have some fairly complex cgroups settings.
– jsbillings
Mar 10 '11 at 15:00
add a comment |
I agree that using cgroups is an excellent way to limit other people from hogging all the CPU cycles on your computer. Sadly, the systems I support (RHEL5) don't have kernels that support it, so I have to stick with adjusting the priority. Once we update to RHEL6, I'm sure we'll have some fairly complex cgroups settings.
– jsbillings
Mar 10 '11 at 15:00
I agree that using cgroups is an excellent way to limit other people from hogging all the CPU cycles on your computer. Sadly, the systems I support (RHEL5) don't have kernels that support it, so I have to stick with adjusting the priority. Once we update to RHEL6, I'm sure we'll have some fairly complex cgroups settings.
– jsbillings
Mar 10 '11 at 15:00
I agree that using cgroups is an excellent way to limit other people from hogging all the CPU cycles on your computer. Sadly, the systems I support (RHEL5) don't have kernels that support it, so I have to stick with adjusting the priority. Once we update to RHEL6, I'm sure we'll have some fairly complex cgroups settings.
– jsbillings
Mar 10 '11 at 15:00
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f8983%2fset-default-nice-value-for-a-given-user-limits-conf%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Somewhat related: unix.stackexchange.com/questions/209398/…
– Kusalananda
Apr 14 at 16:23