On Mon, Apr 15, 2013 at 2:45 AM, Rich Felker <dalias@aerifal.cx> wrote:

> On Sat, Apr 13, 2013 at 11:23:08PM +0100, Justin Cormack wrote:
> > Since glibc 2.2.4, nice() is implemented as a library function that calls
> > getpriority(2) to obtain the new nice value to be returned  to  the
> >  caller.   With this implementation, a successful call can legitimately
> > return -1.  To reliably detect an error, set errno to 0 before the call,
> > and check its value when nice() returns -1.
>
> Thanks for the heads-up. Actually, I think there's a much bigger issue
> with both nice and setpriority: they're affecting one thread rather
> than the process. This may technically not be non-conforming as long
> as SCHED_OTHER scheduling is in effect, but it's sketchy. Basically
> this all stems from a complete failure of Linux to support process
> contention scope and the [PS] option of POSIX... (despite glibc
> claiming to support it!)
>
> In any case, the issue you reported should be fixed. Do you have a
> proposed patch?
>

Something like

--- src/unistd/nice.c-old 2013-04-15 08:16:06.855064898 +0100
+++ src/unistd/nice.c 2013-04-15 08:21:55.920848795 +0100
@@ -3,10 +3,11 @@
 #include "syscall.h"

 int nice(int inc)
-{
 #ifdef SYS_nice
- return syscall(SYS_nice, inc);
+ int ret = syscall(SYS_nice, inc);
 #else
- return setpriority(PRIO_PROCESS, 0, getpriority(PRIO_PROCESS, 0)+inc);
+ int ret = setpriority(PRIO_PROCESS, 0, getpriority(PRIO_PROCESS, 0)+inc);
 #endif
+        if (ret < 0) return ret;
+        return 20-getpriority(PRIO_PROCESS, 0);
 }