Bug 38383 - systemctl started program failed to change scheduling policy
Summary: systemctl started program failed to change scheduling policy
Status: RESOLVED WORKSFORME
Alias: None
Product: systemd
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: IA64 (Itanium) Linux (All)
: medium blocker
Assignee: Lennart Poettering
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-06-16 14:30 UTC by zach.wang
Modified: 2012-03-13 19:14 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Description zach.wang 2011-06-16 14:30:27 UTC
I suspect I'm seeing a bug in systemctl, and here are the steps to reproduce. Please let me know if you need help to reproduce.

1. login to a Fedora 15 as root

2. create a script called "fh2" as in /etc/init.d/fh2

3. In fh2's "start" method, make a call to a small application. In my case, it is /root/test_thread

4. systemctl start fh2.service

5. create another application called "test" in /root. "test" takes from command line the tid of "test_thread", and calls kernel function sched_setscheduler(). The relevant code snippet is pasted below:


 int policy = SCHED_RR;   // SCHED_FIFO;
 struct sched_param sp;
 sp.sched_priority = 1;////sched_get_priority_max(SCHED_FIFO);

 int ret = sched_setscheduler(theTid , policy, &sp);

6. invoke "test" like "test 1234" where 1234 should be the tid of "test_thread" and will be theTid in step 5

7  Notice sched_setscheduler would fail with errono="operation not permitted"

8  Separately, invoke "test_thread" manually in a shell and repeat step 6, and notice sched_setscheduler does not fail this time

9  Since the sched_setscheduler() call fails when a process if invoked by systemctl, I suspect systemctl introduced a bug somewhere when that process is launched.
Comment 1 Lennart Poettering 2011-06-16 14:50:23 UTC
systemd by default puts every service in its own cgroup in the "cpu" hierarchy. This unfortunately has the side effect of disallowing RT for it, since we do not assign an RT budget to it (because there is no sane way to come up with one).

You can either disable this per-service by using "ControlGroup=cpu:/" in the service file or globally by setting DefaultControllers= in /etc/systemd/system.conf.

In the long run we hope this is fixed in the kernel so that we can use the "cpu" hierarchy without assigning an RT budget.
Comment 2 zach.wang 2011-06-16 15:21:50 UTC
I tried both but neither seems to work. For method 1, did you mean to put "ControlGroup=cpu:/" as is in /etc/init.d/fh2 ? For 2, I just uncomment the old line to make it like "DefaultControllers=cpu"? Can you clarify these as I'm not familiar with cgroup?



(In reply to comment #1)
> systemd by default puts every service in its own cgroup in the "cpu" hierarchy.
> This unfortunately has the side effect of disallowing RT for it, since we do
> not assign an RT budget to it (because there is no sane way to come up with
> one).
> 
> You can either disable this per-service by using "ControlGroup=cpu:/" in the
> service file or globally by setting DefaultControllers= in
> /etc/systemd/system.conf.
> 
> In the long run we hope this is fixed in the kernel so that we can use the
> "cpu" hierarchy without assigning an RT budget.
Comment 3 Lennart Poettering 2011-06-17 05:48:20 UTC
(In reply to comment #2)
> I tried both but neither seems to work. For method 1, did you mean to put
> "ControlGroup=cpu:/" as is in /etc/init.d/fh2 ?

No, ControlGroup= is a setting available only in native unit files, not in SysV/LSB scripts.

> For 2, I just uncomment the old
> line to make it like "DefaultControllers=cpu"? Can you clarify these as I'm not
> familiar with cgroup?

The implicit default is "DefaultControllers=cpu", and you should set it to "DefaultControllers=", i.e. remove "cpu" from the line.
Comment 4 zach.wang 2011-06-17 14:17:51 UTC
Cool that worked. Thanks.

(In reply to comment #3)


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.