Since all the child processes are still a part of the session id (sess
in ps
output) we could exploit that fact using this command:
$ parent=6187
$ ps -eo sess:1=,pid:1= |sed -n "s/^$parent //p"
This should return to us all the process IDs of the child processes spawned from lb load
. We can also get this directly from pgrep
, using the -s
switch too.
$ pgrep -s $parent
We can then renice
them like so:
$ renice $(pgrep -s $parent)
Example
Here's a contrived example which hopefully illustrates how this all works. We start with a shell, "PID=10515".
1. Confirm Session ID
$ ps -j
PID PGID SID TTY TIME CMD
10515 10515 10515 pts/8 00:00:00 bash
30781 30781 10515 pts/8 00:00:00 ps
2. Fake jobs
We then start up some fake jobs that we forget to renice
.
$ sleep 10000 &
$ sleep 10000 &
We confirm they're under our shell's session ID (SID
).
$ ps -j
PID PGID SID TTY TIME CMD
10515 10515 10515 pts/8 00:00:00 bash
31107 31107 10515 pts/8 00:00:00 sleep
31111 31111 10515 pts/8 00:00:00 sleep
31140 31140 10515 pts/8 00:00:00 ps
3. Get PIDs associated to SID
We can get a list of all the processes, whose SID
is 10515.
$ pgrep -s 10515
10515
31107
31111
4. Confirm current nice
What's everyone's nice level currently? Use this command to check:
$ ps -eo sess:1=,pid:1=,nice:1= | grep [1]0515
10515 10515 0
10515 31107 0
10515 31111 0
10515 31354 0
10515 31355 0
5. Change nice of all SID descendants
OK so everyone's nice
at 0, let's change that.
$ renice $(pgrep -s 10515)
31107 (process ID) old priority 0, new priority 19
31111 (process ID) old priority 0, new priority 19
6. Confirm
Check our work:
$ ps -eo sess:1=,pid:1=,nice:1= | grep [1]0515
10515 10515 0
10515 31107 19
10515 31111 19
10515 31426 0
10515 31427 0
PIDs 31107 & 31111 are our sleep processes and we just bulk changed their nice to 19 with just the information about what SID
they're associated to.
7. Double check
You can also check ps
output if you're really paranoid:
$ ps -eaf | grep -E "31107|31111"
saml 31107 10515 0 22:30 pts/8 00:00:00 sleep 10000
saml 31111 10515 0 22:30 pts/8 00:00:00 sleep 10000
saml 31531 10515 0 22:35 pts/8 00:00:00 grep --color=auto -E 31107|31111
References
ionice
If you're attempting to control the processes' I/O priority as well as their nice level you should be able to change the above command example around to something like this:
$ renice -n 19 $(pgrep -s $parent)
$ ionice -c 3 -p $(pgrep -s $parent)
If you look at the man page for ionice
you cannot mix -c 3
with -n
.
-c, --class class
Specify the name or number of the scheduling class to use; 0 for
none, 1 for realtime, 2 for best-effort, 3 for idle.
-n, --classdata level
Specify the scheduling class data. This only has an effect if
the class accepts an argument. For realtime and best-effort, 0-7
are valid data (priority levels).
Best Answer
There is big difference between them.
ulimit -e
only set theRLIMIT_NICE
, which is a upper bound value to which the process's nice value can be set usingsetpriority
ornice
.renice
alters the priority of running process.Doing
strace
:Then:
You can see,
ulimit
only callsetrlimit
syscall to change the value ofRLIMIT_NICE
, nothing more.Note
RLIMIT_NICE