Linux

I've been looking online trying to find the correct value nice and priority can take in the limits.conf file. ON the man page it says;
Does this mean priority can be any negative number and any positive?

Then
Does this mean any number between -20 and 19 also what does the definition of nice mean when it mentions Linux 2.6.12 or higher? Does the definition mean you can only set the nice value if you have Linux 2.6.12 or higher?

Sorry if this seems straight forward. I am just a little stuck on these two.

Moderator's Comments:

edit by bakunin: as this has seemingly nothing to do with "Shell Programming and Scripting" i am going to transfer this thread to the Linux forum. You might consider editing in your OS and version so that we can help you more specifically.

Reading the Googled bits, user priority might not be a working facility in all kernels!

Try some modest numbers like +5 and -5. See if it changes the default nice of a new login process (normally 20) or allows nice --5 (permission to raise your priority to nice=15).

Semantically, the - sign haunting nice comes from the use of "nice -19 ....", which does not say set my nice to 19 or -19, but - says option and 19 is what is added to nice. root can go "nice --19" and get a nice=1 child.

I'm sure process priority has been a feature of Linux for much longer than that.

The way it's traditionally worked, though, is that any user can lower their own priority. If you want to create processes of higher priority, you need root access -- partly because you don't want self-important software(or users!) clogging your machine with high-priority processes, partly because ignorantly running things at extremely high priority can be dangerous -- making user mode software higher priority than, say, an interrupt handler would be a Very Bad Thing.

This 2.6.12 feature apparently allows users to raise their own priority without root access, if granted by the system limits file. What's new is this feature in the config file, not process priority itself.

It looks like a good feature to me. There are occasional things which truly need high priority (CD burning, etc) and having to run them as root all the time has always struck me as a bit dicey.

Yes, it's a bit short sighted that UNIX ts mode login goes to the highest allowed priority, rather than somewhere in the middle, like 30. Then, users could tweak their background or other-terminal processes up or down using nice and renice. It's all relative, after all. I guess the real trick is to get out of time sharing into real time mode, like Windows' Realtime!

They even put a 'bgnice' option in ksh at some point, so you could make all background processes nicer by default.

I don't know, it just looks like human nature to me. If you give humans or software the option to raise their priority, they'll all abuse it. Especially since users who don't, are punished by users who do. It's not a go-faster setting after all, it's a give-everyone-else-less setting... Tragedy of the commons again.

If someone wants to lower their priority, however, their intentions are going to be honest.

So you might as well enforce them to be the same, unless they can make do with less.

If you allow for special cases I think it's a good default.

In a more perfect world, the dispatcher would get the CPU to programs that do not hog it and that do i/o on an expedited basis. I remember amazing operators who were copying tape with the difference if I made the job APRIOR, which meant real time. The drive went from "bup bup bup" to "ZZZZZZZZ", and nobody suffered, because it was i/o bound. Programs like that need to take their 1% off the top, which is no harm to the 99%, especially when there is still idle time. Writing dispatches is a big deal some places. One sysadmin refused to kill a looping pg for me, because he said their very custom dispatcher ensured that the CPU it took was off the bottom, so they had a policy to just wait for the periodic reboot.

I believe many schedulers do; I've always been impressed by how well UNIX in general timeshares, compared to Windows' nonstop stuttering. (Not even quad cores helps.) But it only works when they're equal priority... High priority will be favored over low priority regardless of how polite they are. That's what priority's for.

A runaway higher-priority process can lock lower-priority ones out quite harshly; users with the ability to raise their priority can badly affect other users. Starting them at maximum relative to each other prevents them from stalling each other.