How to permanently "renice" a process on Mac OS X (or iOS, etc)?

Question

I use a nice (free) process manager called ATMonitor for Mac OS X that has a lot of cool hidden features, one of which is being able to click on a running process and set the "renice" from +20 (less priority) to -20 (highest priority).

The best part is that it sticks between restarts. So you want XYZ to get full attention all the time, you set it once and it's done.

I want to do the same thing (renice a process) on an iPad running a particular daemon, and I don't know how to set a renice permanently.

I can do it once, and it works fine, but the setting is lost on a reboot. I read somewhere.

Now, as for permanently resetting the priority of a process, this can't be done directly. You can fake it, however, with a shell script that starts the app and then immediately renice's it. Give that script a ".command" extension and it will be double-clickable in the GUI. Not very elegant, but it gets the job done.

But as it says, not very elegant, and I dont think this is how ATMonitor does it.

I found this question and they gave a way to do it as a launch argument, but no apparent way to save it as a persistent value. For instance, if the program wasn't going to be started by launchd.

How do I set a permanent renice level, per executable binary, independent of its PID, when, how, or why it was launched?

Solution 1

After a lot of research, I found a way to create an applescript that will launch and renice a program. It will also take care of the whole administrator password thing for you as well. Just replace the xxxxxxxxx with your own password. I've used this with a range of programs, and all seem to work. Honestly, I can't recall why I put a 1-second delay in it; I think I just wanted to ensure that the program had launched before it reniced. I'm sure there are variations on this script. The nice thing about this is that you don't have to open Activity Monitor, find the process ID, etc. This script does all of that for you. I just save each script as an application, launch it, and everything is zippy. By the way, while I love atMonitor, it does have a reported tendency to suddenly hang your system. See the reviews for it on MacUpdate.

---

tell application "Safari"
    activate
    delay 1
end tell

tell application "System Events" to set unixID to unix id of process "Safari"
do shell script ("renice -20 " & unixID) password "xxxxxxxxx" with administrator privileges

Solution 2

^{Questions about iPad are off-topic on this site, as it is considered an "electronic device"; see the FAQ.}

Answering for Mac OS X:

The changes performed by atMonitor do not actually stick between restarts. They are reapplied when both the application and atMonitor are running again. If you quit atMonitor and restart the reniced application, its nice value is 0 again (verify using the nice column in ps axl). So this method requires you to be running atMonitor.

Besides that, since you can run the actual binary directly, e.g. /Applications/Firefox.app/Contents/MacOS/firefox-bin instead of open -a Firefox, it is impossible to make this change independent of the way the application is started without actually patching the binary itself (which is usually somewhere between crazy complicated and just plain impossible)

You can do what I explained here, but instead of passing command-line arguments, start the application via nice. This will be indistinguishable from the real application as long as you start it using open, the Dock, by double-clicking the application bundle, etc. If you rename the real binary and give the shell script its original name (not changing the Info.plist, even hard-coded invocations will go through your nice script). This will still allow users to launch the (now renamed) binary themselves, but besides that, it'll work.

Comments

[HikeMike]

This question was just bumped to the front page of this site by an automated process. I'd appreciate if you could respond to my answers to both of your questions, either accepting them or mention what doesn't work for you, to give me or others a chance to respond.

[mralexgray]

I guess the "old-fashioned" way to do it would be to just write a shell script and occasionally set the nice levels.. but I am almost sure there is a way to do this via launchd's "limit" [cpu | filesize | data | stack | core | rss | memlock | maxproc | maxfiles] [both [soft | hard]] W/ no arguments, this command prints all the resource limits of launchd as found via getrlimit(2). When a given resource is specified, it prints the limits for that res. 3Args, it sets both the hard and soft lims to that value. w/ 4 arguments, the 3+4 args rep the soft and hard limits respect. I'm just not sure

[mralexgray]

A few questions.. Where do you see "niceness" with ps ax1? I see no change on a prioritized process such as 28328 ?? S< 7:34.19 /System/Library/CoreServices/Finder.app/Contents/MacOS/Finde‌​r before or after a launch of ATMonitor. I am curious why there isn't a "nice" column in "top", either!? Also, with the method you described in your post.. are there any issues with CodeSigning? And would this method also double-up the dock instances as was the case in that example of executing a different binary? And, I know it's a nono, but do you think this'd work on the SpringBoard?

[HikeMike]

@mralexgray It's a lowercase L in ps axl. man top on OS X does not mention nice or priority. It's a special version by Apple, so they likely just didn't bother. Changing stuff in the application bundle will break code signing. You won't get double Dock program instances, at least I didn't when I wrote and tested the linked post; that's why I added that it will look and behave like you expect it to. I have no experience developing for iOS, neither official nor jailbroken, so I cannot answer your question. I guess it's possible to run an atMonitor-like daemon on jailbroken iOS.

[mralexgray]

This solution is novel, and I'm sure, effective.. but it essentially forces you into a non-standard, gasp appleScripted $PATH schema. there's so many ways I can imagine launching the "wrong thing", etc. Let me see if anyone else chimes in, but this is looking close to accepted.

[Hauke Hell]

Although this answer is several years old, I'd like to mention that writing a super user password into a script violates system security. An alternative could be to ask the user in a dialog or call the renice script in a system start script.