-
Notifications
You must be signed in to change notification settings - Fork 30
pthread_create priority thread returns EPERM when run as root #410
Comments
this workaround here seems to fix the issue but i haven't found the underlying cause yet. what other systems have you tried this on and what are the results? |
Yes. That fixed it - thank you. All of the other systems our code is running works out of the box without setting this parameter. Update: Here is Ubuntu 14.04 LTS
Here is Arch Linux:
|
@mischief: I have updated my reply with two examples. Do you need more information from me to investigate this bug? I am more than willing to give output on other distributions if you think that will help. |
what may or may not be very related, systemd defaults put ssh connections into a non-RT cgroup. if you're trying to ssh in and run FIFO/RR tasks, it just won't work. you need to move your shell into the default cpu:/ group which does permit priority scheduling. cgclassify -g cpu:/ $$ your systemd unit file can start your service and get priority scheduling if you put ControlGroup=cpu:/ under [Service] |
@FirefighterBlu3 Thank you - this is good information. I just built an image from the coreOS sdk and booted it using vmware fusion. I tried the same test executing from the console window and it failed. I am not up all of systemd yet - so this is all good info. |
yup. now run cgclassify -g cpu:/ $$ then retry your sched_test program. |
@FirefighterBlu3 |
you can do it alternatively with: echo $$ > /sys/fs/cgroup/cpu/tasks (check path, this is from memory) |
@FirefighterBlu3
|
perhaps it depends on your installation. my Arch installation that i'm working on does exactly this and i have a special need for sched_fifo so i had to figure out why it didn't work when by all expected accounts, it should have. unfortunately the documentation searches on google for cgroup information are still rather sparse but they're starting to get a lot better. arch has some good documentation, redhat has some too. if i had stumbled upon https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Resource_Management_Guide/sec-Moving_a_Process_to_a_Control_Group.html some time back, then i wouldn't have been pulling my hair out for hours. |
Still an issue with 1262.0.0. |
Thank you for reporting this issue. Unfortunately, we don't think we'll end up addressing it in Container Linux. We're now working on Fedora CoreOS, the successor to Container Linux, and we expect most major development to occur there instead. Meanwhile, Container Linux will be fully maintained into 2020 but won't see many new features. We appreciate your taking the time to report this issue and we're sorry that we won't be able to address it. |
Summary:
Setting a thread priority to anything other than zero using a scheduling policy of Round Robin fails with an EPERM when running as root.
Details:
After building the SDK and an image on an Ubuntu 14.04 LTS I tried to set the priority of a thread created as root and received an EPERM. I then pulled the source code below is directly from the man pages for pthread_setschedparam to investigate further and it too returns EPERM when run as root with the command line options
-ar20 -ie
. Just to make sure my SDK or image where not at fault I scp'd the program to a Rackspace machine running the Alpha release and it also failed with EPERM.To compile:
gcc -Wall pthreads_sched_test.c -lpthread -o sched_test
Usage:
Receive an EPERM executing as root:
Set the scheduling policy to SCHED_RR (r), the priority to 20, and the inherit scheduling policy to "explicit".
./sched_test -ar20 -ie
Ulimits are set to "unlimited":
Contents of /etc/os-release
Source code from pthread_setschedparam man page:
The text was updated successfully, but these errors were encountered: