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.
--
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
