I think start-stop-daemon should handle iopriority as well as normal priority. For some background daemons started by initscripts like foldingathome it is logical to have --nice, but currently (at least in linux) it runs at the same io priority as other processes making it "hog" io while for example unpacking/verifying and starting a new core/workunit. Other daemons which could gain from this is samba (which has currently an open bug from someone asking for the possibility to set ionice for the samba server in conf.d) and bittorrent clients running as daemons so they do not "hog" io while verifying content. My suggestion is to add the flag --ionice to start-stop-daemon. Which options it should take is a good question. ionice could be used as an example, it currently takes the following: -c# where # is a value between 1 and 3, describing a priority class (in linux currently realtime, best-eff and idle) and -n# where # is a value between 0-7 describing a priority for "realtime" and "best-eff" priority classes depending on what c# is. If you specify -c3 -n4, then -n4 is discarded as priority class idle does not have any "internal" priority. One way of handling syntax could be: #This should place the program into the "idle" prioclass start-stop-daemon --ionice c3 --exec <program> #This should place the program into the "bet-eff" prioclass with a prio of 7 start-stop-daemon --ionice n7 --exec <program> #This should place the daemon into the "realtime" prioclass with a prio of 5 start-stop-daemon --ionice c1n5 --exec <program> If any devs have any better suggestions on the syntax (I do not know how other operatingsystems/schedulers handling iopriority work, and what options they have available) please feel free to comment. Or if this idea is just plain stupid, please motivate and close.
Roy, what do you think about adding something like this, or can you think of a better syntax?
http://roy.marples.name/projects/openrc/changeset/dc3ccd8101f81803c7a46d4e239911f7d97bed1b Syntax is start-stop-daemon --ionice 1:5 --exec <program>
@Roy Thanks for taking care of this so fast.:-) Now should we wait for a release with this to hit portage, or should we close this bug now?
