3

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.

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).

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.