Re: Problem with chrt
On 09/26/2010 06:04 PM, Gordon Messmer wrote:
On 09/26/2010 12:22 PM, JD wrote:
> $ sudo chrt 0 "./freq -s120 -u0 -r"
> chrt: failed to set pid 0's policy: Invalid argument
> $ sudo chrt 0 './freq -s120 -u0 -r'
> chrt: failed to set pid 0's policy: Invalid argument
0 isn't valid for the default policy (SCHED_RR). "chrt -m" displays the
minimum and maximum values valid for each of the policies.
> #!/bin/sh
> sudo nice --60 ./freq -s120 -u0 -r&
> ps -ef | grep freq | egrep -v 'grep|sudo' | awk '{ print $2 }' |
xargs
> sudo chrt -f -p 0
>
> When I ran it, I got:
> [1] 11340<<<<< This is the pid of the sudo, and not of ./freq
> pid 11348's current scheduling policy: SCHED_OTHER
> pid 11348's current scheduling priority: 0
>
> So, the gist of this is that I requested a FIFO scheduling policy by
> the -f option to chrt.
> Yet, chrt decided to use SCHED_OTHER.
I don't know about the output, but again, 0 isn't valid for the FIFO policy.
So that was the problem!
I was still thinking within the normal process priority values: lower
numbers mean higher pri.
That's what made me look at the source code and I thought well it does
not parse command line,
otherwise why would it quit parsiing.
Should've RTwholeFM :) :)
> The joke is, it does not even parse it's args for the command
the user
> wants to run.
Yes, it does:
# chrt 5 ls
bin boot cgroup dev etc home lib lib64 lost+found media mnt opt
proc root sbin selinux srv sys tmp usr var
> To wit (from soource code):
>
> while((i = getopt_long(argc, argv, "+bfiphmorvV", longopts,
> NULL)) != -1)
getopt_long won't return non-option arguments. Those are parsed later.
getopt returns option arguments and modifies argv to remove them after
parsing. Non-option arguments are left in argv.