5

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 Answers 2

4

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

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

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.