LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Newbie (https://www.linuxquestions.org/questions/linux-newbie-8/)
-   -   renice command failed from RHEL5 (https://www.linuxquestions.org/questions/linux-newbie-8/renice-command-failed-from-rhel5-4175595286/)

JockVSJock 12-12-2016 11:00 AM

renice command failed from RHEL5
 
Trying to renice a command from the CLI with the following syntax, on RHEL5:

Code:


[root@ameda4aisrx0237 ~]# renice -n -10 -p 29083
renice: -10: bad value
29083: old priority 0, new priority 0


[root@ameda4aisrx0237 ~]# renice -n --10 $(pgrep 29083)
0: old priority 0, new priority 0


For the 2nd command, I can get it to work on RHEL7.

Of course, I can renice via top command, however I'm wondering why the syntax isn't working from the CLI.

I've also consulted the following:

http://www.thegeekstuff.com/2013/08/...source=tuicool

thanks

sundialsvcs 12-12-2016 11:37 AM

Notice that the syntax of renice is not consistent among all Unix/Linux systems. For instance, on my Mac, the documentation says that -n means that the number following will be an increment, whereas the same man-page on my Linux virtual machine the implication of the text is that it is an extraneous and meaningless keyword.

It certainly seems possible that release-5 vs. release-7 of RHEL might have changed the syntax and/or the interpretation of this command at some point in time. Check carefully that the documentation is, or isn't, the same. The Linux scheduler has changed quite substantially between releases.

A little puzzled why it isn't letting you, as the superuser, set the priority to -10.

... although here I would insert the usual caveats to the effect that negative priorities, in particular, can cause trouble. As for myself, I only use positive priorities, to designate "batch job type" activities. That is to say: "if a user-interface (UI) mouse-click message arrives right now, should I or should I not interrupt you?" And, that's about the full extent of it. Among the pool of "processes that are RUNNABLE right now," I don't attempt to pick favorites. Instead, I fairly-loosely just try to sort out "the ones who can afford to wait."

"Generally, broad-brushed, speaking," nearly all dispatcher workloads are "I/O-bound," not "CPU," and, by their very nature, forever they will continue to be. So, "niceness" is only of marginal usefulness most of the time.


All times are GMT -5. The time now is 11:48 AM.