GNU bug report logs - #30928
nice: add option to abort on failure to change priority

Previous Next

To reply to this bug, email your comments to 30928 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: L A Walsh <coreutils <at> tlinx.org>
To: bug-coreutils <at> gnu.org
Subject: no error val returned by 'nice' failure?
Date: Sat, 24 Mar 2018 12:37:10 -0700

I executed a command:

nice --19 sleep 5

and hoped to get back a status as to whether or not I was
allowed to use a negative priority, since on Windows,
anyone in the Admin group can set a priority, with
the above command running sleep at 'High' priority, but
on linux:

>  nice --19 sleep 1
nice --19 sleep 1
nice: cannot set niceness: Permission denied
>  echo $?
0

nice has an error setting the priority, but doesn't
set any status in the return code.

Shouldn't nice's exit value be something like
EPERM if it couldn't set the priority -- whether or
not it executed the command...

Otherwise, how do you tell if the resetting of the
priority worked or failed?

Message #8 received at 30928 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: L A Walsh <coreutils <at> tlinx.org>, 30928 <at> debbugs.gnu.org
Subject: Re: bug#30928: no error val returned by 'nice' failure?
Date: Sat, 24 Mar 2018 14:09:21 -0700

L A Walsh wrote:
> how do you tell if the resetting of the
> priority worked or failed?

I guess you're supposed to look at stderr, which is what you did.

This is the way 'nice' has behaved for quite some time, and it's what POSIX 
specifies. We'd need a real good reason to change it, given that changing it 
would no doubt break stuff.

Message #11 received at 30928 <at> debbugs.gnu.org (full text, mbox):

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: Paul Eggert <eggert <at> cs.ucla.edu>, L A Walsh <coreutils <at> tlinx.org>,
 30928 <at> debbugs.gnu.org
Subject: Re: bug#30928: no error val returned by 'nice' failure?
Date: Sun, 25 Mar 2018 00:06:47 +0100

On 03/24/2018 10:09 PM, Paul Eggert wrote:
> L A Walsh wrote:
>> how do you tell if the resetting of the
>> priority worked or failed?
> 
> I guess you're supposed to look at stderr, which is what you did.
> 
> This is the way 'nice' has behaved for quite some time, and it's what POSIX 
> specifies. We'd need a real good reason to change it, given that changing it 
> would no doubt break stuff.

Anyway, it wouldn't harm to document this behavior in the Texinfo
manual... the sentence from the POSIX spec sounds quote good:

  http://pubs.opengroup.org/onlinepubs/9699919799/utilities/nice.html

  If the user lacks appropriate privileges to affect the nice value
  in the requested manner, the nice utility shall not affect the
  nice value; in this case, a warning message may be written to
  standard error, but this shall not prevent the invocation of
  /utility/ or affect the exit status.

Have a nice day,
Berny

Message #14 received at 30928 <at> debbugs.gnu.org (full text, mbox):

From: L A Walsh <coreutils <at> tlinx.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 30928 <at> debbugs.gnu.org
Subject: Re: bug#30928: no error val returned by 'nice' failure?
Date: Sat, 24 Mar 2018 16:32:30 -0700

Paul Eggert wrote:
> L A Walsh wrote:
>> how do you tell if the resetting of the
>> priority worked or failed?
> 
> I guess you're supposed to look at stderr, which is what you did.
> 
> This is the way 'nice' has behaved for quite some time, and it's what POSIX 
> specifies. We'd need a real good reason to change it, given that changing it 
> would no doubt break stuff.
---
How about a flag, like -e for 'fail on failure to change priority' and
(maybe less important or useful) '-w' to only return nice's return 
value, with the posix error message returned for called app (if error).

So, 
 nice -e --19 sleep 99
would return immediately if not root with exit status for EPERM (and
no text); sleep would not be executed.

and for -w case:

 nice -w --19 ls noexist
would return status for EPERM, and message:
ls: cannot access 'noexist': No such file or directory

Seems those would cover most possibly wants, though
the first would be enough to determine if nice is going to work.

Not an earth-shattering change, but at least it would allow
some way to check if nice is going to work or not so
one could not use it where it would fail (and not
generate an error message).

Thanks,..

Message #17 received at 30928 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: L A Walsh <coreutils <at> tlinx.org>, Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 30928 <at> debbugs.gnu.org
Subject: Re: bug#30928: no error val returned by 'nice' failure?
Date: Sat, 31 Mar 2018 16:00:36 -0700

On 24/03/18 16:32, L A Walsh wrote:
> 
> 
> Paul Eggert wrote:
>> L A Walsh wrote:
>>> how do you tell if the resetting of the
>>> priority worked or failed?
>>
>> I guess you're supposed to look at stderr, which is what you did.
>>
>> This is the way 'nice' has behaved for quite some time, and it's what POSIX 
>> specifies. We'd need a real good reason to change it, given that changing it 
>> would no doubt break stuff.
> ---
> How about a flag, like -e for 'fail on failure to change priority' and
> (maybe less important or useful) '-w' to only return nice's return 
> value, with the posix error message returned for called app (if error).
> 
> So, 
>   nice -e --19 sleep 99
> would return immediately if not root with exit status for EPERM (and
> no text); sleep would not be executed.
>  
> and for -w case:
> 
>   nice -w --19 ls noexist
> would return status for EPERM, and message:
> ls: cannot access 'noexist': No such file or directory
> 
> Seems those would cover most possibly wants, though
> the first would be enough to determine if nice is going to work.
> 
> Not an earth-shattering change, but at least it would allow
> some way to check if nice is going to work or not so
> one could not use it where it would fail (and not
> generate an error message).

I wonder could we special case `nice true`
to indicate the nice return, so you could then:

  nice true && nice cmd || exit

That would be forwards compat,
and backwards compat in the sense it would degrade to the current situation.

It's probably a bit hacky though.

Pádraig

Message #20 received at 30928 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Pádraig Brady <P <at> draigBrady.com>,
 L A Walsh <coreutils <at> tlinx.org>
Cc: 30928 <at> debbugs.gnu.org
Subject: Re: bug#30928: no error val returned by 'nice' failure?
Date: Sun, 1 Apr 2018 10:03:01 -0700

Pádraig Brady wrote:
> I wonder could we special case `nice true`
> to indicate the nice return

That would lead to a problem where 'nice true' succeeds but 'nice cmd' (for 
whatever reason) does not. Perhaps the OS has a limit as to how many processes 
you can 'nice', for example. It'd be safer to add an option to avoid such race 
conditions. Plus, as you mention it'd be less hacky, which means it'd be more 
straightforward to document.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.