> Control: tags -1 + upstream > > Hello Frank Heckenbach. > > Thanks for your bug report. > > On Tue, Jul 07, 2015 at 08:48:13PM +0200, Frank Heckenbach wrote: > > Package: util-linux > > Version: 2.25.2-6 > > Severity: normal > > > > % chrt -i 1 sh > > chrt: failed to set pid 0's policy: Invalid argument > > > > Since chrt's arguments are confusing enough already (such as the > > necessary placement of "-p", if used, first and the correspoding pid > > last), a misleading error message is really the last thing it needs. > > > > "pid 0" makes it appear that "-p" was in fact active (for whatever > > reason) and a pid of 0 (again for whatever reason, maybe default) > > pid = 0 is the default if no pid is explicitly specified on command line. > https://git.kernel.org/cgit/utils/util-linux/util-linux.git/tree/schedutils/chrt.c#n314
Not really. There's an internal variable which happens to be called "pid" and defaults to 0. This is passed to sched_[gs]etscheduler which interpret 0 in their first argument (which also happens to be called "pid") to refer to the current process. But these are implementation details that the user doesn't care about. The variable/argument could be called fred with no difference. To the user "pid" in this context means "process id", and a pid is never 0. > > was the problem, since of course pid 0 is really invalid; > > distracting from the fact that the "1" argument to "-i" is in fact > > invalid. > > In comparison this is used on errors to *get* scheduler: > > https://git.kernel.org/cgit/utils/util-linux/util-linux.git/tree/schedutils/chrt.c#n102 And the comment there is quite an euphemism: /* don't display "pid 0" as that is confusing */ "pid 0" is not confusing, it's wrong (see above). > No such equivalent is available on *set: > > https://git.kernel.org/cgit/utils/util-linux/util-linux.git/tree/schedutils/chrt.c#n327 So there should be one. :) Simply replacing "pid" by "pid ? pid : getpid ()" in the error message should do. Or replace "pid = 0;" by "pid = getpid ();" in the default assignment above. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
