Why sudo user can use sched_setscheduler SCHED_RR while root can not?

Question

I am running Arch Linux on a Raspberry Pi 2.

I have a user-space program that uses Gordon's wiringPi library and, in particular, the piHiPri() function that attempts to set the highest priority for the current process (using sched_setscheduler and SCHED_RR mode). This function needs superuser privileges.

The root user is the default one when installing Arch Linux so I created a user named builder that I added to sudoers thanks to visudo.

My problem is: when I execute the program with the root user, the sched_setscheduler function returns “Operation not permitted” (getting it from errno).

If I execute it while being builder I get a “permission denied”.

However if I execute it with sudo myProgram while being builder, everything is fine and I can see that priority has changed with the top command.

I thought that the root user might not have UID 0 so I checked with id -u root but this returns 0.

ls -l myProgramm gives -rwxr-xr-x 1 root root. I also tried to set SUID with chmod +s myProgramm without success.

Any idea on how to make my program executable by root?

EDIT:

As Gilles advised I ran ulimit -r and it returned 0 in any cases (builderand root).

I changed a line in /etc/security/limits.conf from: * - rtprio 0

To : * - rtprio 99

This affected the output of ulimit -r as expected: it returns now 99.

I then tried again to run my program with root but I still have the same Operation not permitted error and now it does not work anymore with sudo (same Operation not permittedas above)... strange !

While investigating I reverted back to old /etc/security/limits.conf settings.

Solution 1

I also got hit by this problem. In my case it turned out that docker daemon has reconfigured default cgroups. As a result root user had cgroup slice with cpu.rt_runtime_us set to zero. In order to set real-time scheduler (either RR or FIFO) you need to have some CPU time assigned. If your process does not have it (when cpu.rt_runtime_us is zero), you will get "permission denied".

More details about cgroups and docker related to this problem are in this error report at RedHat Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1467919

Solution 2

One thing that could explain the difference is if you're ending up with different limits for the maximum realtime priority (ulimit -r). Root cannot exceed the limit, but can raise it. Check with ulimit -r (or, in C, with getrlimit(RLIMIT_RTPRIO, …) and raise the limit before running your program if necessary.

If that doesn't help, it's probably a problem in your program, rather than a problem in your system configuration. Post a small but self-contained source code that reproduces the problem, on Stack Overflow (programming is off-topic on Unix & Linux).